| openstackgerrit | Merged openstack/requirements stable/pike: update constraint for ovsdbapp to new release 0.4.4 https://review.opendev.org/658462 | 00:32 |
|---|---|---|
| *** hongbin has joined #openstack-requirements | 02:39 | |
| *** hongbin has quit IRC | 03:18 | |
| openstackgerrit | Merged openstack/requirements stable/pike: update constraint for os-net-config to new release 7.3.9 https://review.opendev.org/659088 | 03:54 |
| *** udesale has joined #openstack-requirements | 03:58 | |
| tonyb | I'm 99% certain we need the caps for py2 and py3. We just had a bunch of issues where the py2 jobs were getting version from py3. Not everything can use constraints and removing those markers will break *those* jobs | 04:35 |
| prometheanfire | tonyb: I'm not sure WHY that's happening though, perhaps dep calc is beind done in py3 for py2 tests? | 04:39 |
| prometheanfire | I'm aware not everything can use constraits, but for some reason generate-constraints is fine with my proposed patch | 04:40 |
| tonyb | I don't understand how that can be. but you saw the integration gate broke horribly without them | 04:44 |
| tonyb | we hid that by using py3 (which is a good thing) but still unless there is some new dark magic in newer pips? | 04:45 |
| prometheanfire | ya, I'm not sure either | 04:53 |
| *** e0ne has joined #openstack-requirements | 05:05 | |
| *** e0ne has quit IRC | 05:08 | |
| *** spsurya has joined #openstack-requirements | 05:49 | |
| *** e0ne has joined #openstack-requirements | 06:35 | |
| *** tosky has joined #openstack-requirements | 07:27 | |
| *** zigo has quit IRC | 07:28 | |
| *** hberaud|gone is now known as hberaud | 07:40 | |
| *** brinzh has joined #openstack-requirements | 07:40 | |
| *** jpich has joined #openstack-requirements | 07:55 | |
| brinzh | Hi all, anyone can help me to review this error about the cap sphinx on py27. | 08:24 |
| brinzh | http://logs.openstack.org/02/659202/3/check/requirements-check/6469812/job-output.txt.gz#_2019-05-15_07_09_13_480823 | 08:24 |
| brinzh | I have no opinion with it, thks. | 08:26 |
| *** jpich has quit IRC | 08:28 | |
| *** jpich has joined #openstack-requirements | 08:29 | |
| *** dtantsur|afk is now known as dtantsur | 08:35 | |
| *** hberaud has quit IRC | 08:40 | |
| *** hberaud has joined #openstack-requirements | 08:41 | |
| *** brinzhang has joined #openstack-requirements | 09:08 | |
| *** brinzh has quit IRC | 09:10 | |
| *** zigo has joined #openstack-requirements | 09:36 | |
| *** hberaud is now known as hberaud|lunch | 10:07 | |
| *** zigo has quit IRC | 10:30 | |
| *** zigo has joined #openstack-requirements | 10:42 | |
| *** hberaud|lunch is now known as hberaud | 10:58 | |
| *** udesale has quit IRC | 11:08 | |
| *** udesale has joined #openstack-requirements | 11:09 | |
| *** spsurya has quit IRC | 12:08 | |
| *** jpich has quit IRC | 12:20 | |
| *** jpich has joined #openstack-requirements | 12:21 | |
| smcginnis | tonyb: I think the reason it failed before was upper-constraints didn't have the python_versions set that it needed to. | 12:59 |
| smcginnis | tonyb: If we have those set correctly in u-c, I don't see why g-r also needs to have upper caps. | 13:00 |
| smcginnis | Seems a little redundant. | 13:00 |
| *** dangtrinhnt has quit IRC | 13:15 | |
| *** dangtrinhnt has joined #openstack-requirements | 13:16 | |
| *** brinzhang has quit IRC | 13:30 | |
| *** davee_ has joined #openstack-requirements | 14:06 | |
| *** tosky has quit IRC | 15:16 | |
| *** hberaud has quit IRC | 15:17 | |
| *** tosky has joined #openstack-requirements | 15:18 | |
| *** e0ne has quit IRC | 15:50 | |
| *** e0ne has joined #openstack-requirements | 15:50 | |
| openstackgerrit | Matthew Thode proposed openstack/requirements master: Updated from generate-constraints https://review.opendev.org/658636 | 15:51 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: Updated from generate-constraints https://review.opendev.org/658636 | 15:52 |
| prometheanfire | smcginnis: listed what needs to be done to update jsonschema in the review https://review.opendev.org/658636 | 15:52 |
| *** ccamacho has quit IRC | 15:56 | |
| smcginnis | prometheanfire: Comments on there? I don't see anything. | 16:00 |
| smcginnis | Do we still need to capture python 3.4? | 16:01 |
| prometheanfire | smcginnis: patchset 4 | 16:01 |
| prometheanfire | smcginnis: I don't think so, same for py26 | 16:01 |
| prometheanfire | smcginnis: bot overwrote my change a min after I uploaded | 16:01 |
| prometheanfire | working on restoring... | 16:02 |
| openstackgerrit | Andreas Jaeger proposed openstack/requirements master: Updated from generate-constraints https://review.opendev.org/658636 | 16:03 |
| openstackgerrit | Matthew Thode proposed openstack/requirements master: Updated from generate-constraints https://review.opendev.org/658636 | 16:08 |
| *** tosky has quit IRC | 16:13 | |
| *** jpich has quit IRC | 16:38 | |
| openstackgerrit | Walter A. Boring IV (hemna) proposed openstack/requirements master: Add cinder extras infinisdk https://review.opendev.org/658086 | 16:44 |
| openstackgerrit | Walter A. Boring IV (hemna) proposed openstack/requirements master: Add cinder extras pywbem library https://review.opendev.org/658088 | 16:45 |
| openstackgerrit | Walter A. Boring IV (hemna) proposed openstack/requirements master: Add cinder extras purestorage library https://review.opendev.org/658096 | 16:46 |
| openstackgerrit | Merged openstack/requirements stable/pike: update constraint for os-collect-config to new release 7.2.3 https://review.opendev.org/659091 | 17:01 |
| *** dtantsur is now known as dtantsur|afk | 17:01 | |
| *** e0ne has quit IRC | 17:07 | |
| smcginnis | prometheanfire: Any idea what this is about? http://logs.openstack.org/39/659339/2/check/requirements-check/ea930b1/job-output.txt.gz#_2019-05-15_17_05_15_023789 | 17:09 |
| prometheanfire | smcginnis: no, would need to look at source | 17:10 |
| smcginnis | I'm probably missing a small typo or something, but it looks exactly like what was done in other repos successfully and what is in g-r other than the lower limit. | 17:13 |
| prometheanfire | smcginnis: requirements ourself doesn't have separate lines for sphinx | 17:17 |
| smcginnis | prometheanfire: Yeah we do - https://opendev.org/openstack/requirements/src/branch/master/global-requirements.txt#L456 | 17:18 |
| smcginnis | That's what has been causing everyone headaches and why I was pushing for just doing that in upper-constraints. | 17:18 |
| prometheanfire | smcginnis: I'm talking about our doc/requirements.txt | 17:19 |
| smcginnis | Do we run our own check tests against ourselves? I wonder if we will hit it too once we need to change anything there. | 17:20 |
| *** udesale has quit IRC | 17:21 | |
| prometheanfire | it's worth a test, just make the change in our repo and submit | 17:22 |
| openstackgerrit | Sean McGinnis proposed openstack/requirements master: DNM: Test doc req change https://review.opendev.org/659343 | 17:22 |
| *** e0ne has joined #openstack-requirements | 18:10 | |
| *** e0ne has quit IRC | 18:13 | |
| *** tosky has joined #openstack-requirements | 18:43 | |
| *** e0ne has joined #openstack-requirements | 19:17 | |
| *** hberaud has joined #openstack-requirements | 19:52 | |
| *** e0ne has quit IRC | 19:56 | |
| *** e0ne has joined #openstack-requirements | 19:59 | |
| openstackgerrit | Sean McGinnis proposed openstack/requirements master: Make requirements-check output more obvious https://review.opendev.org/659368 | 19:59 |
| prometheanfire | 30 min | 20:00 |
| tonyb[m] | I'm going to be a little late, struggling to get out of bed this morning #professional | 20:26 |
| prometheanfire | heh, been there, back in .au? | 20:26 |
| smcginnis | Given the time there, and that you just travelled around the world, you have a good excuse. | 20:27 |
| *** e0ne has quit IRC | 20:28 | |
| tonyb[m] | Yup got back on (my Monday) | 20:29 |
| prometheanfire | #startmeeting requirements | 20:30 |
| openstack | Meeting started Wed May 15 20:30:09 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:30 |
| *** openstack changes topic to " (Meeting topic: requirements)" | 20:30 | |
| openstack | The meeting name has been set to 'requirements' | 20:30 |
| prometheanfire | #topic rollcall | 20:30 |
| *** openstack changes topic to "rollcall (Meeting topic: requirements)" | 20:30 | |
| prometheanfire | tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann ping | 20:30 |
| prometheanfire | o/ | 20:30 |
| smcginnis | o/ | 20:30 |
| prometheanfire | #topic Any controversies in the Queue? | 20:34 |
| *** openstack changes topic to "Any controversies in the Queue? (Meeting topic: requirements)" | 20:34 | |
| prometheanfire | not too bad, just need to email horizon for django (email list) | 20:35 |
| prometheanfire | added to todo | 20:35 |
| smcginnis | Does that django one fall under the same category as the requests ones? | 20:37 |
| prometheanfire | ya, it really does | 20:37 |
| prometheanfire | dirk: ping | 20:37 |
| prometheanfire | less impact though | 20:37 |
| tonyb[m] | Yeah same idea | 20:38 |
| tonyb[m] | We need to decide how proactive we're going to be there | 20:38 |
| prometheanfire | https://review.opendev.org/658636 | 20:38 |
| prometheanfire | ignore that | 20:38 |
| prometheanfire | ya, I feel like it's all or nothing. as soon as we start accepting some out of tree stuff we become 'secure' and all that bagage | 20:39 |
| tonyb | Yeah there is a little of that | 20:40 |
| tonyb | Still there is scope to 'play' with it and then write up a policy | 20:41 |
| tonyb | I agree with fungi though that it's a vendor thing for the most part *but* I'm pretty sure vendors aren't doign it as well as they could *and* that us doing it is a weaker signal than we'd like :( | 20:42 |
| fungi | i really worry that us attempting to do it poorly ends up being a strong but dangerously misleading signal | 20:43 |
| fungi | honestly, if you want some semblance of a "secure" deployment from source and pypi packages, continuously deploy master and drink from the firehose | 20:44 |
| prometheanfire | what if we accept updates but do not do them ourselves? | 20:45 |
| smcginnis | I wouldn't say continuous from master would be secure, but updating to latest release would be better than expecting a secure stable older branch. | 20:45 |
| prometheanfire | by bot | 20:45 |
| prometheanfire | heh, everyone should be on master at all times | 20:45 |
| tonyb | prometheanfire: that's a pretty weak line to draw | 20:46 |
| tonyb | "it wasn't us" ... just a bot we wrote and ran | 20:46 |
| prometheanfire | proposed updates allowed? | 20:46 |
| prometheanfire | no, I mean not us as in not bot driven | 20:46 |
| fungi | i'll be the first to admit that security isn't an all-or-nothing game, and selectively applying fixes for high-risk vulnerabilities can be useful, but the proposal isn't about doing that it's about upgrading the things which are easy to upgrade rather than the things which are critical to upgrade | 20:46 |
| prometheanfire | if someone wants to come by and propose something.... | 20:46 |
| prometheanfire | as dirk is currently doing, we'd allow that | 20:47 |
| smcginnis | If we did allow it, it has potential for vendors to rally around to watch for security issues. But that's also the argument for extended maintenance, and stable in general hasn't attracted much vendor support. | 20:47 |
| tonyb | fungi: to be fair I don | 20:47 |
| fungi | and when the thing they want to propose requires patching projects in non-backward-compatible ways on stable branches to be able to use newer version whatever of some dependency... we tell them (and users who are relying on this as their only means of securnig python dependencies for openstack source deployments) "tough luck"? | 20:48 |
| tonyb | 't think we;ve formalised the proposal yet | 20:48 |
| smcginnis | Even though many of the vendors are shipping products based on those older releases. | 20:48 |
| tonyb | I *think* it's use publically available data to inform and upgrade pypi packages with known CVEs | 20:48 |
| prometheanfire | fungi: that's the only option we have right now | 20:48 |
| tonyb | I don't know that we have moer than that | 20:48 |
| prometheanfire | tonyb: I think that's the direction dirk wants to head in | 20:48 |
| fungi | we have the option of telling users *clearly* not to rely on this as a secure deployment model, right? | 20:49 |
| tonyb | I *suspect* that the larger chnages or more core chnages will get resistance | 20:49 |
| prometheanfire | fungi: true, that is always an option | 20:49 |
| tonyb | fungi: Yes we can do that | 20:49 |
| smcginnis | Well, maybe for now we should just hold on any of these, then wait for someone to come up with a proposal that's at least marginally sane and maintainable. | 20:49 |
| tonyb | okay | 20:49 |
| tonyb | I don't want to add to dirk's workload but that sounds sane | 20:49 |
| tonyb | dirk: Can you hash out a policy we'll discuss the *policy* on the list with wider input and then implement whatever that outcome is | 20:50 |
| smcginnis | Stable security pop up team? :) | 20:50 |
| fungi | i think whether or not we laggingly apply and test a handful of arbitrary dependency bumps for some external python deps, we have to tell users this isn't a safe solution | 20:50 |
| prometheanfire | what sounds sane? can you add your proposal to https://etherpad.openstack.org/p/non-openstack-stable-security-constraints-updates ? | 20:50 |
| tonyb | fungi: That | 20:51 |
| fungi | because 1. we won't even know about them as far in advance as most of the distros, 2. we can't guarantee we'll be able to apply them since we don't carry forks of our deps where we apply selective backports of fixes | 20:51 |
| tonyb | s fair | 20:52 |
| smcginnis | Is there somewhere we should add a doc warning saying "These were the tested requirements at the time of release but there may be newer security fixes available that have not been thoroughly tested upstream"? Something like that to set the right expectation? | 20:52 |
| smcginnis | Or rather, have somewhere to point to when someone comes along with an issue. | 20:52 |
| prometheanfire | fungi: that's why I had two lists | 20:52 |
| prometheanfire | smcginnis: at min, yes | 20:52 |
| tonyb | +1 | 20:53 |
| fungi | yep, i think both not conflating this solution with the (intentionally frozen) upper constraints list and making it clear to users that this isn't really a significant improvement security-wise are both necessary features of any proposal, i just still question the utility of it at all | 20:54 |
| prometheanfire | I'd rather not do it to be honest | 20:55 |
| fungi | we're basically saying "hey, we sometimes update this other list over here with some more secure dependencies, but you're still going to want to solve the harder problem of updating the ones we can't work out a safe way to update ourselves" | 20:55 |
| fungi | so... why bother? | 20:55 |
| prometheanfire | exactly | 20:56 |
| fungi | the thing we'd be solvnig is the easier and less useful thing to be solved, and users still have to deal with the harder thing they needed solved that we couldn't | 20:56 |
| prometheanfire | I guess I'll point dirk to the meeting notes, but he's really the one pushing it I think | 20:56 |
| fungi | and solving the harder problem solves the easy one anyway | 20:56 |
| smcginnis | The only ones I am concerned about are the LOCI and others like that. But that's kind of a general issue with container images. | 20:57 |
| fungi | at some point they're either going to need to carry patches of dependencies to secure them while keeping them working with stable branches of our software, or carry patches to stable branches of our software to work with newer dependencies | 20:58 |
| prometheanfire | ya, given the way we branch it's not going to support a source based install any other way | 20:59 |
| smcginnis | Containers might be an easier argument to just upgrade to latest anyway. | 20:59 |
| prometheanfire | I know that's what's told in OSA | 20:59 |
| prometheanfire | anything else? I'd recommend adding stuff to https://etherpad.openstack.org/p/non-openstack-stable-security-constraints-updates for this | 21:01 |
| tonyb | I | 21:04 |
| tonyb | ll read it later when I have more coffee onboard | 21:04 |
| prometheanfire | ok | 21:05 |
| tonyb | ... actually looking at my todo list for today it wont happen today | 21:05 |
| prometheanfire | #topic open floor | 21:05 |
| *** openstack changes topic to "open floor (Meeting topic: requirements)" | 21:05 | |
| smcginnis | I'd like to understand why we can't do the python_version capping just in upper-constraints. I don't think I understand that yet, if there actually is a reason. | 21:06 |
| smcginnis | And seeing a lot of grambling in other projects about requirements breaking them now with needing to update their sphinx entries. | 21:06 |
| tonyb | So with my understanding of how pip works, it's just fundamentally needed | 21:07 |
| prometheanfire | do we have a good test case for it?] | 21:08 |
| tonyb | what I don't get is how generate-constraints seemed to do the right thing | 21:08 |
| tonyb | we all saw how the integration job broke without those python_version markers | 21:08 |
| smcginnis | If pip is passed the upper constraints though, it shouldn't have an issue figuring out the max version it can use. | 21:08 |
| smcginnis | I think the job broke because we didn't have the python_version flags in upper-constraints. | 21:08 |
| tonyb | smcginnis: right *if* it's passed one we totally don | 21:09 |
| smcginnis | We just happened to fix that by putting them in g-r instead. | 21:09 |
| prometheanfire | it shouldn't be even trying to figure versions out | 21:09 |
| tonyb | t need the markers in g-r | 21:09 |
| smcginnis | tonyb: But shouldn't projects always be using upper constraints? I would consider that an issue for that project, not u-c vs g-r. | 21:09 |
| tonyb | but *we* should need them to make our tools do the right thing | 21:10 |
| tonyb | smcginnis: in the gate yes | 21:10 |
| tonyb | smcginnis: but nothing actually makes them install with them | 21:10 |
| tonyb | smcginnis: some vendors do a better job than others of staying on top of versions | 21:11 |
| tonyb | and for most vendors they only have one version of python to deal with | 21:11 |
| smcginnis | Kind of makes our debate about raising upper constraints on stable branches moot if we're now saying they aren't used anyway. | 21:11 |
| tonyb | smcginnis: I agree that it's be nice to drop them but without a bunch of understanding of pip I don't see we can (yet) | 21:11 |
| tonyb | smcginnis: A little yes | 21:12 |
| prometheanfire | pip still doesn't dep solve :D | 21:12 |
| smcginnis | OK, at least I understand a little better now. Thanks for explaining it. | 21:12 |
| smcginnis | Hopefully we don't hit too many of these before we can drop py2. | 21:12 |
| prometheanfire | agreed | 21:13 |
| prometheanfire | anything else? | 21:13 |
| tonyb | prometheanfire: that's an over simlification | 21:13 |
| tonyb | I have it on my todo list to look into this but it'll be at least a week | 21:13 |
| prometheanfire | tonyb: I know, was just looking at https://github.com/pypa/pip/issues/988 is all | 21:14 |
| prometheanfire | was looking at it earlier today actually | 21:14 |
| tonyb | Yeah | 21:14 |
| prometheanfire | was mentioned in https://github.com/kennethreitz/requests/issues/5067 | 21:14 |
| prometheanfire | looks like they are targeting 2.22.0 for urllib3/requests | 21:14 |
| prometheanfire | ok, going to close the meeing unless someone speaks up | 21:15 |
| smcginnis | I'm good | 21:15 |
| tonyb | I think it's probably worth writing up something for the list | 21:15 |
| tonyb | to describe what happened last week | 21:16 |
| tonyb | prometheanfire: do you have time to draft something on an etherpad? | 21:16 |
| prometheanfire | tonyb: maybe, not tonight though | 21:17 |
| tonyb | prometheanfire: cool | 21:17 |
| tonyb | prometheanfire: that's still sooner than I could do it ;P | 21:17 |
| prometheanfire | tomorrow at the soonest | 21:17 |
| tonyb | cool beans | 21:19 |
| *** hberaud is now known as hberaud|gone | 21:19 | |
| prometheanfire | #endmeeting | 21:20 |
| *** openstack changes topic to "OpenStack Requirements - IRC meetngs on Wednesdays @ 07:00 UTC in here in #openstack-requirements - See agenda @ http://tinyurl.com/h44ryuw - IRC channel is *LOGGED* @ http://tinyurl.com/j38rk24" | 21:20 | |
| openstack | Meeting ended Wed May 15 21:20:09 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:20 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/requirements/2019/requirements.2019-05-15-20.30.html | 21:20 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/requirements/2019/requirements.2019-05-15-20.30.txt | 21:20 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/requirements/2019/requirements.2019-05-15-20.30.log.html | 21:20 |
| openstackgerrit | Merged openstack/requirements stable/stein: Add safety check output to the linters output https://review.opendev.org/657080 | 22:18 |
| openstackgerrit | Merged openstack/requirements stable/rocky: Add safety check output to the linters output https://review.opendev.org/657106 | 22:19 |
| *** tosky has quit IRC | 23:00 | |
| *** brinzhang has joined #openstack-requirements | 23:41 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!