*** odyssey4me has quit IRC | 00:47 | |
*** odyssey4me has joined #openstack-requirements | 00:47 | |
*** hongbin has joined #openstack-requirements | 01:40 | |
*** andreas_s has joined #openstack-requirements | 02:49 | |
*** andreas_s has quit IRC | 02:54 | |
*** cjloader has joined #openstack-requirements | 03:14 | |
*** cjloader has quit IRC | 03:19 | |
openstackgerrit | Merged openstack/requirements master: be more explicit about the configuration being tested https://review.openstack.org/560049 | 03:21 |
---|---|---|
openstackgerrit | Merged openstack/requirements master: remove optimization for values unchanged from the branch https://review.openstack.org/560050 | 03:21 |
*** udesale has joined #openstack-requirements | 03:34 | |
*** hongbin has quit IRC | 03:59 | |
*** cjloader has joined #openstack-requirements | 04:15 | |
*** cjloader has quit IRC | 04:20 | |
*** udesale has quit IRC | 04:26 | |
*** udesale has joined #openstack-requirements | 04:45 | |
*** udesale has quit IRC | 04:46 | |
*** udesale has joined #openstack-requirements | 04:47 | |
*** cjloader has joined #openstack-requirements | 05:15 | |
*** cjloader has quit IRC | 05:20 | |
*** cjloader has joined #openstack-requirements | 06:14 | |
*** cjloader has quit IRC | 06:19 | |
*** jhesketh_ is now known as jhesketh | 06:29 | |
*** toshii has joined #openstack-requirements | 06:46 | |
toshii | hi | 06:46 |
toshii | good old proposals bot is gone. should I update lower-constraints.txt and requirements.txt in neutron manually? I read through the long mails in openstack-dev but couldn't get an idea. | 06:49 |
prometheanfire | toshii: it's a bit late here, but yes iirc | 06:50 |
prometheanfire | a guide would be useful | 06:50 |
prometheanfire | dhellmann: ^ | 06:50 |
toshii | prometheanfire, thanks | 06:51 |
toshii | I wonder a patch like https://review.openstack.org/#/c/559288/ wasn't necessary after all. | 06:51 |
prometheanfire | really iirc only neutron uses it | 06:54 |
*** florianf has joined #openstack-requirements | 06:58 | |
*** florianf has quit IRC | 06:58 | |
*** florianf has joined #openstack-requirements | 06:58 | |
*** cjloader has joined #openstack-requirements | 07:14 | |
*** cjloader has quit IRC | 07:19 | |
openstackgerrit | Merged openstack/requirements master: exclude cmd2 0.8.3 https://review.openstack.org/560120 | 07:24 |
*** andreas_s has joined #openstack-requirements | 07:34 | |
*** ralonsoh has joined #openstack-requirements | 07:54 | |
*** jpich has joined #openstack-requirements | 07:58 | |
openstackgerrit | Shachar Snapiri proposed openstack/requirements master: Update skydive version to 0.4.4 https://review.openstack.org/560305 | 08:16 |
*** toshii has quit IRC | 09:20 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.messaging to new release 6.1.0 https://review.openstack.org/560342 | 09:56 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for pbr to new release 4.0.2 https://review.openstack.org/560344 | 10:00 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.config to new release 6.0.2 https://review.openstack.org/560345 | 10:00 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.versionedobjects to new release 1.33.0 https://review.openstack.org/560346 | 10:02 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.log to new release 3.38.0 https://review.openstack.org/560347 | 10:03 |
openstackgerrit | Shachar Snapiri proposed openstack/requirements master: Update skydive version to 0.4.4 https://review.openstack.org/560305 | 11:02 |
*** edmondsw has joined #openstack-requirements | 12:08 | |
*** odyssey4me has quit IRC | 12:14 | |
*** odyssey4me has joined #openstack-requirements | 12:14 | |
*** udesale has quit IRC | 13:51 | |
*** ttx has quit IRC | 13:55 | |
*** ttx has joined #openstack-requirements | 13:57 | |
*** udesale has joined #openstack-requirements | 14:00 | |
openstackgerrit | Doug Hellmann proposed openstack/requirements master: remove lower bounds from global requirements https://review.openstack.org/560108 | 14:04 |
openstackgerrit | Doug Hellmann proposed openstack/requirements master: add exclusion specifiers used by swift https://review.openstack.org/560109 | 14:04 |
openstackgerrit | Doug Hellmann proposed openstack/requirements master: remove lower bounds from global requirements https://review.openstack.org/560108 | 14:05 |
openstackgerrit | Doug Hellmann proposed openstack/requirements master: add exclusion specifiers used by swift https://review.openstack.org/560109 | 14:05 |
openstackgerrit | Doug Hellmann proposed openstack/requirements master: remove lower bounds from global requirements https://review.openstack.org/560108 | 14:06 |
openstackgerrit | Doug Hellmann proposed openstack/requirements master: add exclusion specifiers used by swift https://review.openstack.org/560109 | 14:06 |
*** kiennt26 has joined #openstack-requirements | 14:12 | |
*** cjloader has joined #openstack-requirements | 14:56 | |
*** andreas_s has quit IRC | 15:24 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.service to new release 1.31.0 https://review.openstack.org/560469 | 15:24 |
*** andreas_s has joined #openstack-requirements | 15:24 | |
*** andreas_s has quit IRC | 15:38 | |
*** edmondsw has quit IRC | 15:39 | |
*** kiennt26 has quit IRC | 15:41 | |
*** andreas_s has joined #openstack-requirements | 15:43 | |
*** andreas_s has quit IRC | 15:57 | |
*** andreas_s has joined #openstack-requirements | 16:12 | |
prometheanfire | https://www.python.org/dev/peps/pep-0518/ neat | 16:20 |
*** florianf has quit IRC | 16:23 | |
*** andreas_s has quit IRC | 16:25 | |
*** masayukig has joined #openstack-requirements | 16:29 | |
*** andreas_s has joined #openstack-requirements | 16:30 | |
*** jpich has quit IRC | 16:31 | |
prometheanfire | I'm upcapping dateutil in botocore here, btw https://github.com/boto/botocore/pull/1430 | 16:32 |
*** udesale has quit IRC | 16:35 | |
*** andreas_s has quit IRC | 16:49 | |
*** andreas_s has joined #openstack-requirements | 16:54 | |
*** andreas_s has quit IRC | 17:03 | |
*** andreas_s has joined #openstack-requirements | 17:08 | |
*** andreas_s has quit IRC | 17:22 | |
*** andreas_s has joined #openstack-requirements | 17:27 | |
*** ralonsoh has quit IRC | 17:39 | |
*** andreas_s has quit IRC | 17:42 | |
*** andreas_s has joined #openstack-requirements | 17:55 | |
*** edmondsw has joined #openstack-requirements | 17:59 | |
*** andreas_s has quit IRC | 18:10 | |
*** andreas_s has joined #openstack-requirements | 18:14 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for python-glanceclient to new release 2.11.0 https://review.openstack.org/560575 | 18:24 |
*** andreas_s has quit IRC | 18:28 | |
openstackgerrit | Doug Hellmann proposed openstack/requirements master: skip virtualenv setup when there is already a virtualenv https://review.openstack.org/560580 | 19:13 |
dhellmann | prometheanfire : I will babysit the oslo patches for uncapping eventlet but I'm going to need some help with the rest of them. | 19:33 |
*** edmondsw has quit IRC | 19:47 | |
prometheanfire | dhellmann: ya, I have the page up and on my todo list, what'll likely happen for me is that I'll do a review once a day on them (except today since I'm booked) | 20:00 |
dhellmann | prometheanfire : wfm | 20:01 |
openstackgerrit | Dirk Mueller proposed openstack/requirements master: skip virtualenv setup when there is already a virtualenv https://review.openstack.org/560580 | 20:09 |
prometheanfire | tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann: meeting in 20 minutes | 20:10 |
smcginnis | prometheanfire: Wow, I can actually make it. :) | 20:11 |
prometheanfire | smcginnis: yep, we changed the time | 20:11 |
*** dirk__ has joined #openstack-requirements | 20:21 | |
*** dirk has quit IRC | 20:24 | |
*** dirk__ is now known as dirk | 20:24 | |
dhellmann | prometheanfire : in this channel, right? | 20:26 |
prometheanfire | yes | 20:26 |
tonyb | dhellmann: correct'o'mundo | 20:26 |
dhellmann | thanks | 20:27 |
*** mordred has quit IRC | 20:28 | |
*** johnsom has quit IRC | 20:28 | |
*** johnsom has joined #openstack-requirements | 20:29 | |
prometheanfire | 1 min | 20:29 |
prometheanfire | #startmeeting requirements | 20:29 |
openstack | Meeting started Wed Apr 11 20:29:59 2018 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 | so close | 20:30 |
dhellmann | o/ | 20:30 |
prometheanfire | #topic Roll-call | 20:30 |
*** openstack changes topic to "Roll-call (Meeting topic: requirements)" | 20:30 | |
tonyb | \o | 20:30 |
prometheanfire | tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann | 20:30 |
dhellmann | \o | 20:30 |
*** mordred has joined #openstack-requirements | 20:30 | |
prometheanfire | \o/ | 20:30 |
dirk | o/ | 20:30 |
tonyb | huzzah! | 20:30 |
dirk | dhellmann is in australia? | 20:30 |
dhellmann | eastern USA | 20:30 |
tonyb | it's 0630 and today is a success already :) | 20:31 |
prometheanfire | lol | 20:31 |
* dhellmann will return with a beverage in 30 secs | 20:31 | |
prometheanfire | k | 20:31 |
smcginnis | o/ | 20:31 |
prometheanfire | #topic Any controversies in the Queue? | 20:31 |
*** openstack changes topic to "Any controversies in the Queue? (Meeting topic: requirements)" | 20:31 | |
prometheanfire | other than dougs item | 20:31 |
prometheanfire | we should probably discuss that separately | 20:31 |
smcginnis | Is Doug's item the OVO thing you just brought up? | 20:32 |
prometheanfire | no | 20:32 |
prometheanfire | that's not a controversy :P | 20:32 |
prometheanfire | https://review.openstack.org/558604 | 20:32 |
prometheanfire | let's talk about that one | 20:33 |
tonyb | prometheanfire: sure | 20:33 |
* dirk doesn't know the background of that one | 20:33 | |
dhellmann | is 3.26.0 a queens version of oslo.concurrency? | 20:33 |
tonyb | prometheanfire: it's a policy violation | 20:33 |
dhellmann | it doesn't look like it | 20:34 |
dhellmann | https://releases.openstack.org/queens/index.html#queens-oslo-concurrency | 20:34 |
tonyb | dhellmann: no it's the first rocky release | 20:34 |
dhellmann | although that patch linked in the commit message is on queens | 20:34 |
prometheanfire | that's the only problem with it | 20:34 |
dhellmann | this is a security-related thing? | 20:35 |
prometheanfire | the problem the change aims to fix is a security related one | 20:35 |
prometheanfire | yes | 20:35 |
tonyb | I get that we missed the fact that cinder *needs* 3.26.0 but we've missed it that baot has salied | 20:35 |
dhellmann | did we release a new oslo.concurrency from queens? | 20:35 |
prometheanfire | dhellmann: a 3.25.1? | 20:35 |
dirk | yeah, thats my question as well - why aren't security fixes backported anymore to queens series? | 20:36 |
dhellmann | yeah, I guess that's what it would be | 20:36 |
dhellmann | the fix is backported | 20:36 |
prometheanfire | tonyb: so how do we exclude security fails from stable branches? | 20:36 |
dhellmann | they're just going about this wrong | 20:36 |
dhellmann | they need to release from queens and then update the constraint | 20:36 |
dhellmann | then they need to update their code to work if the parameter is not present | 20:36 |
prometheanfire | yes, that's the most optimal solution | 20:36 |
dirk | do we want to allow them to require the version with the security fix on the queens branch? | 20:36 |
tonyb | what dhellmann said | 20:36 |
dhellmann | 3 steps | 20:36 |
prometheanfire | tonyb: can we have !=3.25.0 while updating uc to 3.25.1 then? | 20:37 |
dhellmann | that 3rd step means we don't have to update the min version and distros don't *have* to take the new release | 20:37 |
dhellmann | why would we block the older release? | 20:37 |
prometheanfire | dhellmann: security is the only reason I have | 20:37 |
tonyb | prometheanfire: No we can't havde >=$x,!=$x as that's a policy violation as we're bu,ping the minimum on a stabe; branch | 20:37 |
smcginnis | Yeah, looks like prashkre was confused about how stable requirements are handles with that patch. | 20:37 |
dhellmann | yeah, we don't usually update mins for "bug fixes" regardless of the nature of the bug | 20:37 |
dirk | its an interesting test case for the requirements validator though | 20:38 |
dhellmann | right, I think this is just a matter of needing to educate folks about the right process to follow | 20:38 |
prometheanfire | tonyb: for some reason I thought we did that as a way of not chaning the lower bounds but still effectivly changing the lower bounds | 20:38 |
dirk | it clearly misses that point | 20:38 |
tonyb | prometheanfire: we can look at, given this security related we make an exception but I'm not totally convinced this qualifies | 20:38 |
tonyb | prometheanfire: Nope we don't | 20:38 |
dhellmann | this is a logging security thing, right? not every deployment is going to need to worry about it. | 20:38 |
* prometheanfire could have sworn that we did, but ok | 20:38 | |
prometheanfire | dhellmann: true, the severity isn't the highest | 20:38 |
dhellmann | we allow the constraint to change but we don't try to force the use of the new version | 20:39 |
prometheanfire | I'm ok with that | 20:39 |
tonyb | prometheanfire: If we have done it then it's a human error | 20:39 |
prometheanfire | tonyb: k | 20:39 |
dhellmann | who's going to work with the cinder folks on this? | 20:39 |
prometheanfire | dhellmann: I'm making a comment now | 20:39 |
dhellmann | and bnemec to get that oslo release | 20:40 |
tonyb | dhellmann: Yup, the only complication is for consumers with backports do they just assume they kwarg is there (normally they do) or add additional (not in master) code to handle both cases | 20:40 |
dhellmann | I guess I'm the oslo release liaison, so I could just do that | 20:40 |
dhellmann | tonyb : they need to not assume it is there | 20:40 |
dhellmann | which probably means not a clean backport | 20:41 |
tonyb | I'm happy to propose the backport and release if bnemec and dhellmann are okay with it | 20:41 |
prometheanfire | commented | 20:41 |
dhellmann | sure, I can +1/+2 the release | 20:41 |
prometheanfire | next | 20:41 |
prometheanfire | https://review.openstack.org/555269 | 20:41 |
tonyb | dhellmann: cool. I'll post them today | 20:41 |
prometheanfire | can we just abandon that? | 20:41 |
tonyb | prometheanfire: Yup | 20:42 |
prometheanfire | done | 20:42 |
tonyb | prometheanfire: we don't add setuptools to u-c as manytimes it's a bootstrap problem | 20:42 |
prometheanfire | ya, I commented as such | 20:43 |
prometheanfire | now if only gertty would catch up | 20:43 |
tonyb | also newton is EOL so we're closed for business there | 20:43 |
prometheanfire | tonyb: this one's yours | 20:43 |
prometheanfire | https://review.openstack.org/551111 | 20:43 |
tonyb | prometheanfire: Oh yeah I need to rebase it now the master version has mereged | 20:44 |
tonyb | I'll do that today | 20:44 |
prometheanfire | k | 20:44 |
prometheanfire | #topic remove lower bounds from global requirements | 20:45 |
*** openstack changes topic to "remove lower bounds from global requirements (Meeting topic: requirements)" | 20:45 | |
prometheanfire | #link https://review.openstack.org/560108 | 20:45 |
prometheanfire | dhellmann: you're up | 20:45 |
tonyb | also 55 11 11 is a cool change number ;P | 20:45 |
prometheanfire | tonyb: indeed | 20:45 |
prometheanfire | I was envious when I saw it | 20:45 |
tonyb | ahh small things :) | 20:45 |
dhellmann | right, so we're almost done with the changes to allow lower bound divergence and add lower-constraints tests | 20:45 |
dhellmann | the one thing that's left is that we have a few projects, swift notably among them, that still have lower lower bounds than g-r has | 20:46 |
dhellmann | and different exclusions | 20:46 |
dhellmann | I'm trying to sync those up so we can get the lower-constraints job in place | 20:46 |
dhellmann | and as I point out in my comment on the bug, I see 4 options | 20:46 |
dhellmann | 1. Force projects to update their minimums. I include this for completeness, but think it's a terrible idea. | 20:46 |
dhellmann | 2. Force projects to drop those exclusions. I also think this is a terrible idea and unlikely to result in wide-spread adoption. | 20:46 |
dhellmann | 3. Add exclusions to the global-requirements list that are lower than the >= value. I don't know if anything else will complain about this, but it will certainly look odd if it does work. | 20:46 |
dhellmann | 4. Remove the minimum values here. These values are demonstrably wrong, since I have had to update the lower-constraints patches in many cases to use different values. We also know that some projects support lower versions than are specified here, and we want to allow that. | 20:47 |
dhellmann | I went with the last option, because it felt like it made the most sense | 20:47 |
dhellmann | prometheanfire indicated that option 3 might be preferred, and I could live with that, but it's going to look weird | 20:47 |
prometheanfire | dhellmann: my prefrence is for 4, but fall back to 3 if we still require tracking the minimums for some reason I don't know of | 20:48 |
dirk | dhellmann: what do you mean by demonstratably wrong? | 20:48 |
dhellmann | I would like to resolve this so I can move off of this work, because I do have other things I need to do this cycle | 20:48 |
dhellmann | dirk : I mean that given the number of times I've had to change the lower-constraints.txt file in projects based on the original list, those lower bounds are higher than they need to be in a lot of cases. | 20:48 |
prometheanfire | dhellmann: a patch doing option 3 would be intreresting to test though (just to see what breaks) | 20:49 |
dhellmann | and also that as we go forward in time, projects are going to drift apart from each other and from that list | 20:49 |
dirk | dhellmann: ah, ok. so its the case where a project supports an older version than the g-r min version is. ok | 20:49 |
dhellmann | dirk : yes, that's right | 20:49 |
dirk | dhellmann: but those older versions wouldn't be coinstallable | 20:49 |
dhellmann | dirk : maybe. I do not have a goal of making the lower bounds co-installable. | 20:49 |
dhellmann | and I think that is the source of a lot of the conflict and confusion over these changes | 20:49 |
dhellmann | I want the values in each project repo to be accurate. I don't care if they're the same. | 20:50 |
dhellmann | We are providing a list of co-installable versions. Other people may want to produce other lists. I don't think the community needs to maintain multiple lists. | 20:50 |
dhellmann | If we *do* maintain multiple lists, I think we need to do it in a way that does not add friction to the project teams. | 20:50 |
dirk | it might be all obvious but I havent' been able to find the time to closely look at what has been done | 20:50 |
dhellmann | and I think trying to maintain a single central list does add too much friction | 20:50 |
dirk | are the projects running sensible tests against their in-project lower constraints? ike a functional test suite? or unit tests? | 20:51 |
dhellmann | for now most of them are just running unit tests | 20:51 |
dirk | are they all at least running unit tests? | 20:51 |
openstackgerrit | Matthew Thode proposed openstack/requirements master: Add swift exclusions https://review.openstack.org/560636 | 20:51 |
tonyb | dirk: unit tests but it's totally doable to add funcational tests | 20:51 |
dhellmann | some are. not all have landed the job. not all of the jobs are working | 20:52 |
dhellmann | https://review.openstack.org/#/q/status:open++topic:requirements-stop-syncing | 20:52 |
dhellmann | most of the major projects have added the unit test job | 20:52 |
prometheanfire | distros don't care that openstack is co-installable for the lower version if they have multiple versions available to install | 20:53 |
prometheanfire | distros should install what is co-installable if they can (dep solving is there for a reason) | 20:53 |
prometheanfire | at least that's my perspective from gentoo | 20:53 |
tonyb | prometheanfire: I'm not sure that's dirk's POV with hsi distro hat on | 20:53 |
dhellmann | right, I suspect we could have a different set of co-installable versions from each vendor. | 20:53 |
prometheanfire | ya, that's why I said gentoo :p | 20:53 |
dhellmann | well, I respect the right of distros to use different versions. I do not think it is our job to test those versions for them. | 20:54 |
dirk | prometheanfire: in almost all cases the uc version isn't available yet due to $reasons | 20:54 |
dirk | because uc updates within hours of the upstream release | 20:54 |
dhellmann | this is an area where we could completely consume all community testing resources (human and bot) to satisfy this need | 20:54 |
*** edmondsw has joined #openstack-requirements | 20:54 | |
dhellmann | and I don't think the *community* benefit warrants doing that | 20:54 |
prometheanfire | dhellmann: agreed (Openstack isn't responsible for disto testing) | 20:55 |
dhellmann | I also don't think these changes make that work any harder | 20:55 |
dirk | I agree to the latter part | 20:55 |
dirk | removing the lower bounds from g-r.txt doesn't change anything in that area | 20:55 |
tonyb | dirk: really? | 20:55 |
dhellmann | it would be relatively straightforward to build a tool to read lower-constraints.txt files from a set of repos and build a "highest min" set of projects | 20:56 |
tonyb | dirk: I thought you wanted to maintain a global-maximum list of minimums | 20:56 |
dhellmann | and *that* set would be (a) accurate and (b) targeted to the projects being packaged | 20:56 |
dirk | tonyb: what am I missing? remember it is very late here and I had a very long and stressful day :) | 20:56 |
tonyb | and removeing the minimums from g-r makes that *much* harder | 20:56 |
dhellmann | tonyb : no, it doesn't, because those numbers are *already wrong* | 20:56 |
prometheanfire | dhellmann: that's what I've been wanting to track in a separate file | 20:56 |
prometheanfire | pull vs push the min | 20:57 |
dirk | tonyb: but those numbers are tracked in the lower-constraints.txt in the requirements repo already? | 20:57 |
prometheanfire | but that's a separate project | 20:57 |
dhellmann | I'm not sure why we need to check the results of that file in, but ok | 20:57 |
dirk | right now they're just duplicated | 20:57 |
dhellmann | dirk : exactly | 20:57 |
dirk | dhellmann: we could generate it from the sum of projects indeed | 20:57 |
tonyb | dhellmann: Yes they're wrong I don't deny that | 20:57 |
prometheanfire | dhellmann: just as an aid to deployers, like you said it's easy to generate we could even not track the file ourselves and just give deployers the tool + instructions on how to use it | 20:58 |
dhellmann | dirk : right. that would let other people track the values for you, and you could consume them as a "point in time" set of values when you need them | 20:58 |
tonyb | dhellmann: but that's ok while we fix them Stien+ if we set expectations | 20:58 |
dhellmann | prometheanfire : sure | 20:58 |
dhellmann | tonyb : the "fix" is going to be to lower a bunch of values. Are you ok with that? | 20:58 |
tonyb | dirk: If you're okay with that outcome then I'm fine with it | 20:58 |
prometheanfire | so, about your patch, I voted | 20:58 |
tonyb | dirk: but we ruled that out in Denver ... I don't recall why :/ | 20:59 |
prometheanfire | I think we are all ok with option 4 | 20:59 |
prometheanfire | which is what his patch represents | 20:59 |
tonyb | dhellmann: I'm not sure that's the case | 20:59 |
dirk | tonyb: I'm certainly not able to recall that at this time of the day anymore either | 20:59 |
*** edmondsw has quit IRC | 20:59 | |
tonyb | dhellmann: I've been quiet as I'm working through a question "is it wrong for $project to have a lower minimum that g-r" | 21:00 |
dirk | yeah, exactly | 21:00 |
dhellmann | dirk : maybe tomorrow (or another day) during more normal hours you could write up what you'd like to be able to do with a "highest min" set of values and send that to the ML, and then I can try to respond there | 21:00 |
dirk | many of those subtleties in all the changes that we did are not clear to me | 21:00 |
tonyb | dhellmann: I *think* that's okay as the minimums in g-r were s'posed to represent the global minimums | 21:01 |
dhellmann | tonyb : we already have projects that are like that and it causes no issues | 21:01 |
prometheanfire | tonyb: individually no, I don't think it's a problem | 21:01 |
dhellmann | I'm trying to enable 2 new cases | 21:01 |
prometheanfire | tonyb: that's my understanding as well | 21:01 |
dhellmann | 1. Separate installations of a service without a bunch of newer dependencies | 21:01 |
dirk | dhellmann: I think thats in the README.rst alread of the repo. basically integration test rather than unit test of the lower constraints of the core projects | 21:01 |
dhellmann | 2. Stable libraries appearing stable because their requirements don't change automatically | 21:01 |
dhellmann | dirk : ok. I think to do that you do need to have a way to produce a "highest min" set of values, but you want it for the projects being tested not the global list | 21:02 |
dirk | dhellmann: in many cases from what I've seen complicated external deps are mocked in unit tests so running unit tests against lower constraints does not actually tell that the lower requirements would work outside a unit test env | 21:02 |
dhellmann | because projects.txt includes *tons* of things in it that are probably irrelevant for your distribution | 21:02 |
dhellmann | I agree, that's likely the case | 21:02 |
dhellmann | whether we track a set of values centrally or not won't change that | 21:03 |
dirk | dhellmann: right, aiming a full global lower-constraints is too much. starting with a $set of projects and combining theirs lower-constrains might be better | 21:03 |
dirk | but I wonder how we would want to resolve conflict in a tool. so thats why you still end up maintaining a file | 21:03 |
tonyb | dhellmann: No, but the central lower-constraints.txt was supposed to make an integrated run "easy" | 21:03 |
dhellmann | if we can stabilize what we have now, and have those unit tests running, that should give project teams the confidence to set up functional test jobs | 21:04 |
dhellmann | and we could make that a goal for stein or T | 21:04 |
prometheanfire | we should be figuring out what the highest global min is (if we care to) not prescribing what it is | 21:04 |
prometheanfire | so removal makes sense to me | 21:04 |
dhellmann | tonyb : it makes it slightly easier to run the job at the expense of making it much harder to fix the list when the job fails | 21:04 |
dhellmann | well, slightly harder | 21:04 |
tonyb | dhellmann: Yeah for me it was an acceptable level of pain ... but my setpint is probably off | 21:05 |
dirk | dhellmann: I guess I'll have to start a test job that runs against the lc to see how bad it is to get it to work | 21:06 |
dhellmann | I'm trying to reduce the number of patches we need to make to the requirements repo, to cut load on this team and to reduce friction for project teams who want to make changes in their own repo | 21:06 |
tonyb | anyway I *think* we've all agreed that er can remove the minimums in g-r and them's that care can maintain the lower-constratints.txt in openstack/requirements | 21:06 |
dirk | yep, +1 | 21:06 |
tonyb | is that the simple take away? | 21:06 |
prometheanfire | yes | 21:06 |
dirk | exactly | 21:06 |
dirk | one step at a time, we'll all be more wise tomorrow | 21:06 |
dhellmann | yeah, I don't mind keeping the lower-constraints.txt file (although I reserve the right to change my mind if it causes problems later) | 21:06 |
prometheanfire | lol | 21:07 |
tonyb | dhellmann: ;P that's pretty much the std. disclaimer on IRC ;P | 21:07 |
dirk | dhellmann: I'd really like to understand the problems you'e been hitting more concretely btw, so if you could tell me obvious take aways that you learned while doing that work in a more detailed fashion, I'd be happy to listen | 21:07 |
dhellmann | once we have a tool to build that file from a bunch of repos, then the question is just when it makes sense to run it -- on a merge that changes lower-constraints in a repo, or inside the lower bounds integration job when it runs | 21:08 |
dirk | (doesn't have to be now) | 21:08 |
tonyb | okay so we did reach consensus. | 21:08 |
prometheanfire | open floor next? | 21:08 |
dhellmann | dirk : I had to use https://review.openstack.org/#/c/558610/ to fix a bunch of the original lower-constraints.txt files in various repos | 21:08 |
dhellmann | so I think the global lower-constraints file is a "highest min" but within each project I needed the *actual* min | 21:09 |
prometheanfire | #topic open floor | 21:09 |
*** openstack changes topic to "open floor (Meeting topic: requirements)" | 21:10 | |
dhellmann | and if those are already different, then we've already drifted apart (yay!) but that means the global values are already not right | 21:10 |
dhellmann | thank you all for hashing this out one more time | 21:10 |
dirk | dhellmann: right, I agree the highest-min currently are also actually likely a bit higher then the actually lowest highest min | 21:10 |
* dhellmann is getting confused with the conflicting highest-lowest-highest qualifiers | 21:11 | |
dhellmann | :-) | 21:11 |
tonyb | dhellmann: Yeah it's always a problem ;P | 21:11 |
dirk | yeah | 21:11 |
dirk | this is tricky | 21:11 |
dhellmann | lowest-coinstallable-set? | 21:11 |
dirk | yes | 21:11 |
prometheanfire | dhellmann: took me a while to get used to | 21:11 |
dhellmann | maybe that's a better name then | 21:11 |
prometheanfire | the global highest min may not be co-installable | 21:12 |
prometheanfire | project-b may have a != on it or something | 21:12 |
tonyb | lowest-coinstallable-set-that-may-work-but-probably-not.txt ;P | 21:12 |
tonyb | or is that a little passive aggressive ? | 21:12 |
prometheanfire | tonyb: yes, lets use that :D | 21:12 |
dhellmann | prometheanfire : no, because we enforce that projects cannot exclude things that are not also excluded in the global list | 21:12 |
prometheanfire | no, I like it :D | 21:12 |
prometheanfire | dhellmann: true, so.. should be good | 21:12 |
dhellmann | tonyb : just-dont-even-try-it.txt? | 21:12 |
dhellmann | maybe that's too aggressive :-) | 21:13 |
tonyb | dhellmann: #winner ;P | 21:13 |
prometheanfire | anyone have any other topics before I close? | 21:13 |
dirk | can you remind us about other prios other than no req sync? | 21:13 |
dirk | I've just seen that py36 patch that I neglected to followup | 21:13 |
prometheanfire | dirk: what do you mean? other things to do this cycle? | 21:14 |
dirk | yes | 21:14 |
dirk | or upcoming things to worry about | 21:14 |
prometheanfire | uncapping and py36 are the main things I guess | 21:14 |
tonyb | dirk: Yeah we need to sort out and test py36 this cycle | 21:14 |
dhellmann | we have https://review.openstack.org/#/q/topic:uncap-eventlet | 21:14 |
prometheanfire | if you are working on p36 I can focus on uncapping eventlet | 21:14 |
prometheanfire | dhellmann: ++ | 21:14 |
prometheanfire | anyone have anything else? | 21:15 |
dirk | it looks liekt he cross job worked but neutron and some others failed on py36 | 21:15 |
dirk | well, I guess finding-sensible-goal-for-dont-try-it-txt :-) | 21:16 |
tonyb | I'd like to work out if we can switch *constratints.txt to use <= and > in python_version markers | 21:16 |
dhellmann | what are we doing with 3.6? that seems like a community-wide thing | 21:16 |
dirk | providing+generating a py36 compatible uc | 21:16 |
dhellmann | tonyb : is that related to my hacky evaluation logic? | 21:16 |
prometheanfire | tonyb: that's a nice to have thing imo | 21:16 |
tonyb | dhellmann: There are some aspects we need to nail down before the community can make meaningful progress | 21:16 |
dhellmann | dirk : so we don't just assume what we have now works and let project teams tell us otherwise when their jobs fail? | 21:16 |
tonyb | dhellmann: partially but I really don't like that we basically have ==3.4 ; ==3.5 and ==3.6 | 21:17 |
dhellmann | the next thing I was going to get to work on was updating some secondary jobs like docs and release notes to run on python 3, but I was just going to say "3" not "3.5" or "3.6" | 21:17 |
dirk | dhellmann: the principle of g-r so far was "we know it better than you" ;-) | 21:17 |
dirk | now with the g-r sync disabled I guess we have to find a new mission | 21:18 |
tonyb | dhellmann: it's just wrong and we're basically making up thr 3.4 and 3.6 data anyway | 21:18 |
dirk | dhellmann: the review I was talking about is https://review.openstack.org/#/c/554824/ | 21:18 |
dhellmann | tonyb : sure. maybe the thing to do is get the packaging library to expose the resolver in a better way so we can reuse it | 21:18 |
prometheanfire | dirk: we record the wisdom of the masses :P | 21:18 |
dhellmann | right now it assumes no one is going to pass environment values in, but we need to be able to do that | 21:18 |
dhellmann | dirk : I think this team is too small and overworked to stick with that "we know better" policy :-/ | 21:18 |
* dirk isn't that small | 21:18 | |
tonyb | dhellmann: I'm not sure what we can get out of packaging to make this better | 21:19 |
tonyb | dhellmann: but if you have ideas I'm open | 21:19 |
* prometheanfire fits neatly into overhead bins | 21:19 | |
dhellmann | I think the most valuable thing to do is maintain the g-r list in terms of licenses and "goodness" and to start encouraging teams to reduce the number of redundant dependencies we have | 21:19 |
prometheanfire | dhellmann: that's a constant work in progress | 21:19 |
dhellmann | tonyb : they have a thing to evaluate the environment markers against the current environment. we just need a version of that where we can pass environment values into it instead of having it compute them for us | 21:19 |
dirk | dhellmann: yeah, dropping redundant/bad dependencies (e.g. not py3 comptible) would be a good goal to work on | 21:20 |
dirk | if you're working for a distro then openstack is still a major pain | 21:20 |
dhellmann | so we can say "we're going to pretend to be python 2.7 even though we're 3.5, does this rule evaluate to true?" | 21:20 |
tonyb | dhellmann: Hmmm I'm not sure that'd help as we don't have a system that has py3.4, py3.5 and py3.6 on it to get real data | 21:20 |
dhellmann | I think *many* people would appreciate reducing redundant dependencies as a goal. I'm not sure many developers would. :-) | 21:20 |
prometheanfire | dhellmann++ | 21:21 |
dirk | dhellmann: usually noone minds if somebody else does the work.. | 21:21 |
dhellmann | tonyb : I think I worked out that we don't need all of those values. We only need to be able to say "do these two sets of environment markers evaluate as compatible" | 21:21 |
dirk | it was so far never a problem to cleanup stuff if you spent the time to figure out how to port it from one tech to another tech | 21:21 |
prometheanfire | that's what I'm finding with the cryptography migration... | 21:21 |
tonyb | dirk: that's partially true by $project now needs to grok as some level $new_lib instead of $old_lib and that's a pain point | 21:22 |
dhellmann | that was one of the benefits of having thin wrappers for some things in oslo; we could change the underlying implementation without having to change every app | 21:22 |
dirk | tonyb: are we over complexifying the problem? | 21:22 |
tonyb | dirk: I don't think so | 21:23 |
dirk | tonyb: wouldn't it be enough to let the proposal bot to suggest something and then we test it on some other nodepool slave with the $right python version whether that is satisfactory? | 21:23 |
dirk | I m not sure many libs have conflicting dependencies for individual py3.x versions | 21:23 |
tonyb | dirk: I don't think that works. | 21:23 |
dirk | ok, tell me why? | 21:23 |
prometheanfire | I know botocore has problems with py3.3, but that's it (and couldn't understand the PDT timezone in 3.6 for some reason) | 21:24 |
tonyb | dirk: It's not really about conflicting dependencies, it's about generating a constraints file that's valid and actually constrains things | 21:24 |
tonyb | dirk: And do you really want to start setting up meta reviews? | 21:25 |
dirk | right, validity checks can be done in our existing check-uc job | 21:25 |
dhellmann | why are we using == for several versions now instead of >='3.5'? | 21:25 |
tonyb | dhellmann: That's the root of the question | 21:25 |
dhellmann | maybe we should just change the list and see what we end up with | 21:26 |
tonyb | dhellmann: it could be that the answer is "because lifeless made a mistake, we approved it and ran with it", but it could equally be "lifeless considered things from $y angle and we've forgotten it" | 21:26 |
dhellmann | yeah | 21:26 |
dhellmann | I suspect that when we switch to 3.6 we're not going to need to worry about supporting 3.5 any more | 21:27 |
prometheanfire | we can continue discussing this after the meeting, we are coming up on time | 21:27 |
dhellmann | until we are off of 2.7 I don't see us supporting more than one version of 3.x | 21:27 |
dhellmann | ok | 21:27 |
tonyb | splitting on <3.$x where $x would vary based on out CI environment (4 for xenial 6 for biaonic) is right | 21:27 |
tonyb | it's certainly simplier | 21:27 |
prometheanfire | tonyb++ | 21:27 |
tonyb | I guess we need to ask lifeless | 21:27 |
dhellmann | we don't need to support 3.4 though | 21:27 |
prometheanfire | that's my understanding as why we need multiple py3 versions as well | 21:27 |
dhellmann | at least not on master | 21:28 |
prometheanfire | #endmeeting | 21:28 |
*** 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:28 | |
openstack | Meeting ended Wed Apr 11 21:28:09 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:28 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-04-11-20.29.html | 21:28 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-04-11-20.29.txt | 21:28 |
openstack | Log: http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-04-11-20.29.log.html | 21:28 |
tonyb | dhellmann: Yeah on $branch we'd have a minimum 3.4, 3.6 etc | 21:28 |
dhellmann | we've been trying to support multiple versions of 3 because we're still working our way fully onto 3 | 21:28 |
dhellmann | when we do make it onto 3, I think we'll all be on 3.6 everywhere | 21:28 |
dhellmann | and we can drop 3.x testing on older branches | 21:28 |
dhellmann | no one is actually distributing things on 3 for older branches | 21:28 |
prometheanfire | dhellmann: I agree that's likely | 21:28 |
dhellmann | at least I hope not | 21:28 |
prometheanfire | I package py3 versions of openstack | 21:29 |
prometheanfire | I'm running py3 on my cluster at home | 21:29 |
prometheanfire | iirc openstack ansible is using py3 for some things too | 21:29 |
dhellmann | ok | 21:29 |
dhellmann | so we don't drop anything on old branches | 21:29 |
dhellmann | but we don't need to carry over the old 3.x versions on master | 21:29 |
prometheanfire | ack | 21:29 |
dirk | its just a constraints file anyway? | 21:30 |
dirk | e.g. it contains massive amount of information in order to be as complete as possible | 21:30 |
tonyb | dhellmann: Yeah, and the way the tools are written that's a very simple thing to do once we cross that point (3.6+ everywhere) | 21:30 |
dhellmann | yeah | 21:30 |
dhellmann | any day now | 21:30 |
prometheanfire | lol | 21:30 |
tonyb | :) | 21:31 |
dhellmann | it's wine-o'clock here so I'm going to call it a day | 21:31 |
prometheanfire | yep, I'm about to head home now too | 21:31 |
prometheanfire | catch you later | 21:31 |
smcginnis | o/ | 21:31 |
dhellmann | tonyb : I assume you'll vote on https://review.openstack.org/#/c/560108/ after you get the kids off to school? | 21:32 |
tonyb | dhellmann: done. (the vote not the trip to school) | 21:35 |
tonyb | and with that I go AFK | 21:35 |
dhellmann | tonyb : thanks | 21:36 |
*** cjloader_ has joined #openstack-requirements | 21:42 | |
*** cjloader has quit IRC | 21:42 | |
*** cjloader_ has quit IRC | 21:47 | |
*** andreas_s has joined #openstack-requirements | 22:26 | |
-openstackstatus- NOTICE: zuul was restarted to updated to the latest code; you may need to recheck changes uploaded or approvals added between 21:30 and 21:45 | 22:30 | |
*** andreas_s has quit IRC | 22:31 | |
*** cjloader has joined #openstack-requirements | 22:32 | |
jlvillal | dhellmann, prometheanfire: I proposed https://review.openstack.org/#/c/560675/ so that we can fix gate for Ironic stable/pike. | 22:33 |
jlvillal | But let me know if prefer to backport the mentioned commit. I didn't backport it because it touched things I wasn't sure if we should backport. | 22:33 |
*** cjloader has quit IRC | 22:37 | |
prometheanfire | jlvillal: I think I'm fine with adding to blacklist in a stable branch, I don't think we have a rule around it | 22:42 |
prometheanfire | tonyb: ^ | 22:42 |
jlvillal | prometheanfire, thanks | 22:42 |
*** edmondsw has joined #openstack-requirements | 22:43 | |
tonyb | jlvillal: Can you point me at a fialinf change and wht the fix in ironic looks like | 22:48 |
*** edmondsw has quit IRC | 22:48 | |
jlvillal | tonyb, What? 'fialinf'? | 22:48 |
tonyb | jlvillal: I'm kinda confused how pycodestyle is getting invloved in your linters on pike | 22:48 |
tonyb | jlvillal: *failing* | 22:48 |
tonyb | jlvillal: the commit message states that ironic is broken so surely you have a failing change | 22:49 |
prometheanfire | tonyb: let me see if I can find the refrence, but a flake8-* lib is pulling it in (not flake8 itself) | 22:49 |
prometheanfire | tonyb: https://github.com/openstack/ironic/blob/stable/pike/test-requirements.txt#L22 | 22:50 |
jlvillal | tonyb, I'm seeing errors like this: http://paste.openstack.org/show/718997/ | 22:50 |
prometheanfire | https://github.com/PyCQA/flake8-import-order/blob/0.11/setup.py#L38 | 22:50 |
tonyb | Okay so https://review.openstack.org/#/c/560556/ is what I was looking for | 22:52 |
jlvillal | tonyb, Ah! I thought you wanted an error showing the failing PEP8 errors. | 22:53 |
tonyb | jlvillal: I did, but that commit links to those errors, and the full .tox logs so I can work out what's going on | 22:53 |
jlvillal | tonyb, The change you posted is the reason I proposed my patch https://review.openstack.org/#/c/560675/ | 22:53 |
tonyb | jlvillal: adding it to the blacklist will mean that all projects that are affected have to fix it locally | 22:54 |
tonyb | jlvillal: it seems like we shoudl be able to do something smarter | 22:54 |
jlvillal | tonyb, I'm confused? What projects have it listed? | 22:54 |
tonyb | prometheanfire: https://github.com/PyCQA/flake8-import-order/blob/0.11/setup.py#L32 is the relevant line | 22:55 |
jlvillal | tonyb, I don't think 'pycodestyle' can be in any requirements.txt or test-requirements.txt because it isn't in global-requirements | 22:55 |
tonyb | jlvillal: If we add it to the blacklist all projects will have to do something like what you're doing in ironic which seems sub-optimal | 22:55 |
prometheanfire | tonyb: yep, I just linked the first one I saw | 22:56 |
tonyb | jlvillal: Right so I think the right solution is to put it in g-r (and u-c) and ban the broken version | 22:56 |
tonyb | but we need to think through that | 22:56 |
jlvillal | tonyb, Okay. That sounds reasonable to me also. I'm not sure how many other projects are affected by this. | 22:57 |
tonyb | jlvillal: I've +2'd the openstack/requirements change with a comment. It's sub-optimal but I guess we made that choice last year. | 23:08 |
jlvillal | tonyb, Okay. Thanks! | 23:09 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!