20:30:04 <prometheanfire> #startmeeting requirements
20:30:05 <openstack> Meeting started Wed May  8 20:30:04 2019 UTC and is due to finish in 60 minutes.  The chair is prometheanfire. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:30:06 <smcginnis> It is odd to me the log showed it picked up taskflow 3.4.0 earlier though. That version should have pulled in the right dependencies.
20:30:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:30:09 <openstack> The meeting name has been set to 'requirements'
20:30:13 <prometheanfire> #topic roll call
20:30:15 <smcginnis> o/
20:30:22 <prometheanfire> tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann ping
20:30:25 <prometheanfire> o/
20:31:43 <dirk> o/
20:32:51 <prometheanfire> #topic Any controversies in the Queue?
20:33:08 <tonyb> \o
20:33:10 <smcginnis> The Cinder driver one.
20:33:10 <prometheanfire> requests
20:33:24 <prometheanfire> and safety check in linters
20:33:38 <prometheanfire> but that's it
20:33:44 <prometheanfire> so, first, requests
20:33:48 <prometheanfire> dirk: want to take that?
20:33:51 <prometheanfire> or talk about it
20:34:19 * tonyb[m] lost connectivity to his normal IRC account
20:34:29 <prometheanfire> tonyb: k
20:35:20 <dirk> prometheanfire: no updates yet, I started runnign the local tests today but then meeting madness started (not this meeting)
20:35:34 <prometheanfire> of course, this meeting is insanity
20:35:48 <tonyb[m]> insanely good!
20:36:09 <prometheanfire> dirk: ok, please update with your results, you want to update to the new (unpublished) release as well?
20:36:16 <prometheanfire> dirk: update the list that is
20:36:41 <dirk> prometheanfire: yep
20:37:03 <prometheanfire> cinder driver review, I think we are good here, dirk and tonyb asked them to split the review
20:37:53 <dirk> I"m also trying to comment on funghi's topic
20:38:02 <tonyb[m]> I do think that some of the 'problematic' ones will need more work so it might also be good to make the same split on the cinder side
20:38:07 <dirk> it looks like both kolla and loci seem to be using "our" constraints
20:38:09 <prometheanfire> dirk: ya, it is a point that's been brought up before
20:38:24 <prometheanfire> tonyb: yep, they emailed the list statting they may have to do that
20:38:40 <prometheanfire> dirk: osa uses them but can add exceptions
20:38:57 <tonyb[m]> fungi's topic?
20:39:18 <dirk> fungi left a comment questioning that we change uc on stable branches for security sake
20:39:25 <prometheanfire> don't update constraints becaues then people will expect it
20:39:32 <dirk> he is afraid that it is a road to regressions
20:39:42 <prometheanfire> it in the list for the requests update thread
20:40:45 <fungi> yep
20:40:51 <fungi> that's a reasonable summary
20:41:21 <prometheanfire> ok, safety check in linters
20:41:50 <tonyb[m]> Oh right I follow nwow
20:41:58 <tonyb[m]> now even
20:42:15 <prometheanfire> for this one I know it runs fast but I don't like conflating lint checks and safety type checks in one 'yes/no'
20:42:23 <prometheanfire> right meow?
20:42:35 <tonyb[m]> I think that's fine
20:42:58 <dirk> prometheanfire: its the same like other projects they run pep8/flake8 and bandit in the same job
20:43:09 <fungi> if you need to update requests to a new release to avoid a security flaw in it, you may in turn need to update to a newer urllib3 and that may in turn require newer... on down until you hit something which needs updating in one of our projects to support
20:43:11 <dirk> prometheanfire: technically the tox -epep8 should be renamed to tox -elinters imho
20:43:16 <prometheanfire> that's true, and goodenough for me, if we need to split later on we can
20:43:18 <tonyb[m]> I know just beacuse others do it isn't a good reason, but plenty of other places do linting a checking at the same time
20:43:23 <prometheanfire> dirk: that's true too
20:43:33 <prometheanfire> fungi: yep
20:43:42 <dirk> prometheanfire: therewas a plan to rename pep8 to linters but it seems with zuulv3 this is now super painful *as you have to land a change in 1 billion repos
20:43:52 <prometheanfire> lol
20:44:05 <fungi> or super easy to just change in your repo and ignore everyone else? ;)
20:44:06 <prometheanfire> ok, any other controversies?
20:44:15 <dirk> fungi: I agree, requests is annoying (also that it is branchless and doesn't maintain older versions with security fixes)
20:44:42 <fungi> i doubt it's the only one of our ~600 constraints entries which has those characteristics
20:44:56 <tonyb[m]> fungi: true
20:45:16 <dirk> fungi: I ran the saftey security checker against stable/pike the list is not short but its just a few packages
20:45:34 <dirk> fungi: all the *good ones* of course (pycrytpo, cryptography, django, requests, ...)
20:45:46 <fungi> also by the time security "fixes" percolate through our backporting of constraints bumps, deployers will have already needed to solve this on their side (or else they don't actually care about the security of their deployments, really)
20:46:10 <prometheanfire> fungi: it's the latter
20:46:40 <fungi> if you're using a deployment based on distro packages of dependencies, your distro has probably already pushed out fixed packages before we even know there's a vulnerability
20:46:45 <prometheanfire> #topic open floor
20:46:55 <prometheanfire> ya, if using disto packages
20:47:14 <dirk> fungi: all the container deployers that opensetack offers (kolla, loci, osa) seem to just use upperconstraints
20:47:26 <dirk> fungi: building binary wheels from that
20:47:26 <fungi> that's frightening
20:47:30 <dirk> fungi:  it is
20:47:56 <dirk> to talk about something more fun
20:48:28 <dirk> given that there are a thousand "switch to opendev.org url" reviews out there, we need to accellerate our efforts to push out *sane* upper-constraint urls
20:48:53 <tonyb[m]> Sure
20:48:56 <dirk> I have seen two to three variants, depending on who did the review. also some reviews that point to 404 urls (whcih pip in -c seems to happily ignore and just install unconstrained)
20:49:12 <dirk> so I think I pushed a review to add TOX_CONSTRAINTS
20:49:15 <prometheanfire> dirk: they do, but if the security check was gated on in them they could do that
20:49:17 <dirk> but I can't find it anymore
20:49:41 <tonyb[m]> :(
20:50:10 <tonyb[m]> I think we shoudl just do it and ask for forgiveness for not doing everything in one hit
20:50:11 <dirk> prometheanfire: right, but isn't it better to maintain that list in one place than having 3 different deployers compete in the combination of broken dependency versions they choose
20:50:47 <dirk> what we could do is separate it out into unsafe-but-working-constraints.txt and safe-but-potentially-broken-constraints.txt
20:50:59 <tonyb[m]> I feel like it's basically a 5-line shell script maybe 10 if I handle errors
20:51:05 <dirk> then people can chose if they want stability or safety ;-]
20:51:35 <prometheanfire> dirk: that's true, but also makes security 'our problem' rather than each deployment project's problem
20:51:38 <dirk> prometheanfire: one thing I want to do is to switch to a pure-ascii output in the safety check
20:51:53 <dirk> as it doesn't render too well from logs.o.org (it looked great when run locally)
20:52:01 <prometheanfire> ya
20:52:20 <dirk> prometheanfire: our problem is to review, not to fix stuff
20:52:24 <prometheanfire> tonyb: so you are accelerating the TOX_CONSTRAINTS thing?
20:52:30 <dirk> and I can take the reviews
20:52:40 <tonyb[m]> prometheanfire: I don't have the bandwith for that work right now
20:52:44 <prometheanfire> dirk: true, but that's a bit reductionist :P
20:53:17 <tonyb[m]> prometheanfire: I can to the 'switch to https://releases.o.o/...' work on at least master and probably stable/*
20:53:33 <tonyb[m]> prometheanfire: I doubt I'll have time to fix all the bitrot but I can start the process
20:53:57 <prometheanfire> tonyb[m]: that'd be a good start and head off a bunch of the reviews
20:54:06 <tonyb[m]> Yup
20:54:18 <tonyb[m]> at least a few bad ones have merged
20:54:29 <prometheanfire> yep
20:54:35 <prometheanfire> anyone else have topics?
20:54:58 <smcginnis> not me
20:56:01 <dirk> tonyb:  https://review.opendev.org/657886 would be the first step I think
20:56:05 <prometheanfire> #endmeeting