Wednesday, 2018-04-11

*** odyssey4me has quit IRC00:47
*** odyssey4me has joined #openstack-requirements00:47
*** hongbin has joined #openstack-requirements01:40
*** andreas_s has joined #openstack-requirements02:49
*** andreas_s has quit IRC02:54
*** cjloader has joined #openstack-requirements03:14
*** cjloader has quit IRC03:19
openstackgerritMerged openstack/requirements master: be more explicit about the configuration being tested  https://review.openstack.org/56004903:21
openstackgerritMerged openstack/requirements master: remove optimization for values unchanged from the branch  https://review.openstack.org/56005003:21
*** udesale has joined #openstack-requirements03:34
*** hongbin has quit IRC03:59
*** cjloader has joined #openstack-requirements04:15
*** cjloader has quit IRC04:20
*** udesale has quit IRC04:26
*** udesale has joined #openstack-requirements04:45
*** udesale has quit IRC04:46
*** udesale has joined #openstack-requirements04:47
*** cjloader has joined #openstack-requirements05:15
*** cjloader has quit IRC05:20
*** cjloader has joined #openstack-requirements06:14
*** cjloader has quit IRC06:19
*** jhesketh_ is now known as jhesketh06:29
*** toshii has joined #openstack-requirements06:46
toshiihi06:46
toshiigood 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
prometheanfiretoshii: it's a bit late here, but yes iirc06:50
prometheanfirea guide would be useful06:50
prometheanfiredhellmann: ^06:50
toshiiprometheanfire, thanks06:51
toshiiI wonder a patch like https://review.openstack.org/#/c/559288/ wasn't necessary after all.06:51
prometheanfirereally iirc only neutron uses it06:54
*** florianf has joined #openstack-requirements06:58
*** florianf has quit IRC06:58
*** florianf has joined #openstack-requirements06:58
*** cjloader has joined #openstack-requirements07:14
*** cjloader has quit IRC07:19
openstackgerritMerged openstack/requirements master: exclude cmd2 0.8.3  https://review.openstack.org/56012007:24
*** andreas_s has joined #openstack-requirements07:34
*** ralonsoh has joined #openstack-requirements07:54
*** jpich has joined #openstack-requirements07:58
openstackgerritShachar Snapiri proposed openstack/requirements master: Update skydive version to 0.4.4  https://review.openstack.org/56030508:16
*** toshii has quit IRC09:20
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.messaging to new release 6.1.0  https://review.openstack.org/56034209:56
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for pbr to new release 4.0.2  https://review.openstack.org/56034410:00
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.config to new release 6.0.2  https://review.openstack.org/56034510:00
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.versionedobjects to new release 1.33.0  https://review.openstack.org/56034610:02
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.log to new release 3.38.0  https://review.openstack.org/56034710:03
openstackgerritShachar Snapiri proposed openstack/requirements master: Update skydive version to 0.4.4  https://review.openstack.org/56030511:02
*** edmondsw has joined #openstack-requirements12:08
*** odyssey4me has quit IRC12:14
*** odyssey4me has joined #openstack-requirements12:14
*** udesale has quit IRC13:51
*** ttx has quit IRC13:55
*** ttx has joined #openstack-requirements13:57
*** udesale has joined #openstack-requirements14:00
openstackgerritDoug Hellmann proposed openstack/requirements master: remove lower bounds from global requirements  https://review.openstack.org/56010814:04
openstackgerritDoug Hellmann proposed openstack/requirements master: add exclusion specifiers used by swift  https://review.openstack.org/56010914:04
openstackgerritDoug Hellmann proposed openstack/requirements master: remove lower bounds from global requirements  https://review.openstack.org/56010814:05
openstackgerritDoug Hellmann proposed openstack/requirements master: add exclusion specifiers used by swift  https://review.openstack.org/56010914:05
openstackgerritDoug Hellmann proposed openstack/requirements master: remove lower bounds from global requirements  https://review.openstack.org/56010814:06
openstackgerritDoug Hellmann proposed openstack/requirements master: add exclusion specifiers used by swift  https://review.openstack.org/56010914:06
*** kiennt26 has joined #openstack-requirements14:12
*** cjloader has joined #openstack-requirements14:56
*** andreas_s has quit IRC15:24
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for oslo.service to new release 1.31.0  https://review.openstack.org/56046915:24
*** andreas_s has joined #openstack-requirements15:24
*** andreas_s has quit IRC15:38
*** edmondsw has quit IRC15:39
*** kiennt26 has quit IRC15:41
*** andreas_s has joined #openstack-requirements15:43
*** andreas_s has quit IRC15:57
*** andreas_s has joined #openstack-requirements16:12
prometheanfirehttps://www.python.org/dev/peps/pep-0518/ neat16:20
*** florianf has quit IRC16:23
*** andreas_s has quit IRC16:25
*** masayukig has joined #openstack-requirements16:29
*** andreas_s has joined #openstack-requirements16:30
*** jpich has quit IRC16:31
prometheanfireI'm upcapping dateutil in botocore here, btw https://github.com/boto/botocore/pull/143016:32
*** udesale has quit IRC16:35
*** andreas_s has quit IRC16:49
*** andreas_s has joined #openstack-requirements16:54
*** andreas_s has quit IRC17:03
*** andreas_s has joined #openstack-requirements17:08
*** andreas_s has quit IRC17:22
*** andreas_s has joined #openstack-requirements17:27
*** ralonsoh has quit IRC17:39
*** andreas_s has quit IRC17:42
*** andreas_s has joined #openstack-requirements17:55
*** edmondsw has joined #openstack-requirements17:59
*** andreas_s has quit IRC18:10
*** andreas_s has joined #openstack-requirements18:14
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for python-glanceclient to new release 2.11.0  https://review.openstack.org/56057518:24
*** andreas_s has quit IRC18:28
openstackgerritDoug Hellmann proposed openstack/requirements master: skip virtualenv setup when there is already a virtualenv  https://review.openstack.org/56058019:13
dhellmannprometheanfire : 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 IRC19:47
prometheanfiredhellmann: 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
dhellmannprometheanfire : wfm20:01
openstackgerritDirk Mueller proposed openstack/requirements master: skip virtualenv setup when there is already a virtualenv  https://review.openstack.org/56058020:09
prometheanfiretonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann: meeting in 20 minutes20:10
smcginnisprometheanfire: Wow, I can actually make it. :)20:11
prometheanfiresmcginnis: yep, we changed the time20:11
*** dirk__ has joined #openstack-requirements20:21
*** dirk has quit IRC20:24
*** dirk__ is now known as dirk20:24
dhellmannprometheanfire : in this channel, right?20:26
prometheanfireyes20:26
tonybdhellmann: correct'o'mundo20:26
dhellmannthanks20:27
*** mordred has quit IRC20:28
*** johnsom has quit IRC20:28
*** johnsom has joined #openstack-requirements20:29
prometheanfire1 min20:29
prometheanfire#startmeeting requirements20:29
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:30
*** openstack changes topic to " (Meeting topic: requirements)"20:30
openstackThe meeting name has been set to 'requirements'20:30
prometheanfireso close20:30
dhellmanno/20:30
prometheanfire#topic Roll-call20:30
*** openstack changes topic to "Roll-call (Meeting topic: requirements)"20:30
tonyb\o20:30
prometheanfiretonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann20:30
dhellmann\o20:30
*** mordred has joined #openstack-requirements20:30
prometheanfire\o/20:30
dirko/20:30
tonybhuzzah!20:30
dirkdhellmann is in australia?20:30
dhellmanneastern USA20:30
tonybit's 0630 and today is a success already :)20:31
prometheanfirelol20:31
* dhellmann will return with a beverage in 30 secs20:31
prometheanfirek20:31
smcginniso/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
prometheanfireother than dougs item20:31
prometheanfirewe should probably discuss that separately20:31
smcginnisIs Doug's item the OVO thing you just brought up?20:32
prometheanfireno20:32
prometheanfirethat's not a controversy :P20:32
prometheanfirehttps://review.openstack.org/55860420:32
prometheanfirelet's talk about that one20:33
tonybprometheanfire: sure20:33
* dirk doesn't know the background of that one20:33
dhellmannis 3.26.0 a queens version of oslo.concurrency?20:33
tonybprometheanfire: it's a policy violation20:33
dhellmannit doesn't look like it20:34
dhellmannhttps://releases.openstack.org/queens/index.html#queens-oslo-concurrency20:34
tonybdhellmann: no it's the first rocky release20:34
dhellmannalthough that patch linked in the commit message is on queens20:34
prometheanfirethat's the only problem with it20:34
dhellmannthis is a security-related thing?20:35
prometheanfirethe problem the change aims to fix is a security related one20:35
prometheanfireyes20:35
tonybI get that we missed the fact that cinder *needs* 3.26.0 but we've missed it that baot has salied20:35
dhellmanndid we release a new oslo.concurrency from queens?20:35
prometheanfiredhellmann: a 3.25.1?20:35
dirkyeah, thats my question as well - why aren't security fixes backported anymore to queens series?20:36
dhellmannyeah, I guess that's what it would be20:36
dhellmannthe fix is backported20:36
prometheanfiretonyb: so how do we exclude security fails from stable branches?20:36
dhellmannthey're just going about this wrong20:36
dhellmannthey need to release from queens and then update the constraint20:36
dhellmannthen they need to update their code to work if the parameter is not present20:36
prometheanfireyes, that's the most optimal solution20:36
dirkdo we want to allow them to require the version with the security fix on the queens branch?20:36
tonybwhat dhellmann said20:36
dhellmann3 steps20:36
prometheanfiretonyb: can we have !=3.25.0 while updating uc to 3.25.1 then?20:37
dhellmannthat 3rd step means we don't have to update the min version and distros don't *have* to take the new release20:37
dhellmannwhy would we block the older release?20:37
prometheanfiredhellmann: security is the only reason I have20:37
tonybprometheanfire: No we can't havde >=$x,!=$x as that's a policy violation as we're bu,ping the minimum on a stabe; branch20:37
smcginnisYeah, looks like prashkre was confused about how stable requirements are handles with that patch.20:37
dhellmannyeah, we don't usually update mins for "bug fixes" regardless of the nature of the bug20:37
dirkits an interesting test case for the requirements validator though20:38
dhellmannright, I think this is just a matter of needing to educate folks about the right process to follow20:38
prometheanfiretonyb: for some reason I thought we did that as a way of not chaning the lower bounds but still effectivly changing the lower bounds20:38
dirkit clearly misses that point20:38
tonybprometheanfire: we can look at, given this security related we make an exception but I'm not totally convinced this qualifies20:38
tonybprometheanfire: Nope we don't20:38
dhellmannthis 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 ok20:38
prometheanfiredhellmann: true, the severity isn't the highest20:38
dhellmannwe allow the constraint to change but we don't try to force the use of the new version20:39
prometheanfireI'm ok with that20:39
tonybprometheanfire: If we have done it then it's a human error20:39
prometheanfiretonyb: k20:39
dhellmannwho's going to work with the cinder folks on this?20:39
prometheanfiredhellmann: I'm making a comment now20:39
dhellmannand bnemec to get that oslo release20:40
tonybdhellmann: 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 cases20:40
dhellmannI guess I'm the oslo release liaison, so I could just do that20:40
dhellmanntonyb : they need to not assume it is there20:40
dhellmannwhich probably means not a clean backport20:41
tonybI'm happy to propose the backport and release if bnemec and dhellmann are okay with it20:41
prometheanfirecommented20:41
dhellmannsure, I can +1/+2 the release20:41
prometheanfirenext20:41
prometheanfirehttps://review.openstack.org/55526920:41
tonybdhellmann: cool.  I'll post them today20:41
prometheanfirecan we just abandon that?20:41
tonybprometheanfire: Yup20:42
prometheanfiredone20:42
tonybprometheanfire: we don't add setuptools to u-c as manytimes it's a bootstrap problem20:42
prometheanfireya, I commented as such20:43
prometheanfirenow if only gertty would catch up20:43
tonybalso newton is EOL so we're closed for business there20:43
prometheanfiretonyb: this one's yours20:43
prometheanfirehttps://review.openstack.org/55111120:43
tonybprometheanfire: Oh yeah I need to rebase it now the master version has mereged20:44
tonybI'll do that today20:44
prometheanfirek20:44
prometheanfire#topic remove lower bounds from global requirements20:45
*** openstack changes topic to "remove lower bounds from global requirements (Meeting topic: requirements)"20:45
prometheanfire#link https://review.openstack.org/56010820:45
prometheanfiredhellmann: you're up20:45
tonybalso 55 11 11 is a cool change number ;P20:45
prometheanfiretonyb: indeed20:45
prometheanfireI was envious when I saw it20:45
tonybahh small things :)20:45
dhellmannright, so we're almost done with the changes to allow lower bound divergence and add lower-constraints tests20:45
dhellmannthe 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 has20:46
dhellmannand different exclusions20:46
dhellmannI'm trying to sync those up so we can get the lower-constraints job in place20:46
dhellmannand as I point out in my comment on the bug, I see 4 options20:46
dhellmann1. Force projects to update their minimums. I include this for completeness, but think it's a terrible idea.20:46
dhellmann2. Force projects to drop those exclusions. I also think this is a terrible idea and unlikely to result in wide-spread adoption.20:46
dhellmann3. 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
dhellmann4. 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
dhellmannI went with the last option, because it felt like it made the most sense20:47
dhellmannprometheanfire indicated that option 3 might be preferred, and I could live with that, but it's going to look weird20:47
prometheanfiredhellmann: my prefrence is for 4, but fall back to 3 if we still require tracking the minimums for some reason I don't know of20:48
dirkdhellmann: what do you mean by demonstratably wrong?20:48
dhellmannI would like to resolve this so I can move off of this work, because I do have other things I need to do this cycle20:48
dhellmanndirk : 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
prometheanfiredhellmann: a patch doing option 3 would be intreresting to test though (just to see what breaks)20:49
dhellmannand also that as we go forward in time, projects are going to drift apart from each other and from that list20:49
dirkdhellmann: ah, ok. so its the case where a project supports an older version than the g-r min version is. ok20:49
dhellmanndirk : yes, that's right20:49
dirkdhellmann: but those older versions wouldn't be coinstallable20:49
dhellmanndirk : maybe. I do not have a goal of making the lower bounds co-installable.20:49
dhellmannand I think that is the source of a lot of the conflict and confusion over these changes20:49
dhellmannI want the values in each project repo to be accurate. I don't care if they're the same.20:50
dhellmannWe 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
dhellmannIf 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
dirkit might be all obvious but I havent' been able to find the time to closely look at what has been done20:50
dhellmannand I think trying to maintain a single central list does add too much friction20:50
dirkare the projects running sensible tests against their in-project lower constraints? ike a functional test suite? or unit tests?20:51
dhellmannfor now most of them are just running unit tests20:51
dirkare they all at least running unit tests?20:51
openstackgerritMatthew Thode proposed openstack/requirements master: Add swift exclusions  https://review.openstack.org/56063620:51
tonybdirk: unit tests but it's totally doable to add funcational tests20:51
dhellmannsome are. not all have landed the job. not all of the jobs are working20:52
dhellmannhttps://review.openstack.org/#/q/status:open++topic:requirements-stop-syncing20:52
dhellmannmost of the major projects have added the unit test job20:52
prometheanfiredistros don't care that openstack is co-installable for the lower version if they have multiple versions available to install20:53
prometheanfiredistros should install what is co-installable if they can (dep solving is there for a reason)20:53
prometheanfireat least that's my perspective from gentoo20:53
tonybprometheanfire: I'm not sure that's dirk's POV with hsi distro hat on20:53
dhellmannright, I suspect we could have a different set of co-installable versions from each vendor.20:53
prometheanfireya, that's why I said gentoo :p20:53
dhellmannwell, 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
dirkprometheanfire: in almost all cases the uc version isn't available yet due to $reasons20:54
dirkbecause uc updates within hours of the upstream release20:54
dhellmannthis is an area where we could completely consume all community testing resources (human and bot) to satisfy this need20:54
*** edmondsw has joined #openstack-requirements20:54
dhellmannand I don't think the *community* benefit warrants doing that20:54
prometheanfiredhellmann: agreed (Openstack isn't responsible for disto testing)20:55
dhellmannI also don't think these changes make that work any harder20:55
dirkI agree to the latter part20:55
dirkremoving the lower bounds from g-r.txt doesn't change anything in that area20:55
tonybdirk: really?20:55
dhellmannit 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 projects20:56
tonybdirk: I thought you wanted to maintain a global-maximum list of minimums20:56
dhellmannand *that* set would be (a) accurate and (b) targeted to the projects being packaged20:56
dirktonyb: what am I missing? remember it is very late here and I had a very long and stressful day :)20:56
tonyband removeing the minimums from g-r makes that *much* harder20:56
dhellmanntonyb : no, it doesn't, because those numbers are *already wrong*20:56
prometheanfiredhellmann: that's what I've been wanting to track in a separate file20:56
prometheanfirepull vs push the min20:57
dirktonyb: but those numbers are tracked in the lower-constraints.txt in the requirements repo already?20:57
prometheanfirebut that's a separate project20:57
dhellmannI'm not sure why we need to check the results of that file in, but ok20:57
dirkright now they're just duplicated20:57
dhellmanndirk : exactly20:57
dirkdhellmann: we could generate it from the sum of projects indeed20:57
tonybdhellmann: Yes they're wrong I don't deny that20:57
prometheanfiredhellmann: 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 it20:58
dhellmanndirk : 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 them20:58
tonybdhellmann: but that's ok while we fix them Stien+ if we set expectations20:58
dhellmannprometheanfire : sure20:58
dhellmanntonyb : the "fix" is going to be to lower a bunch of values. Are you ok with that?20:58
tonybdirk: If you're okay with that outcome then I'm fine with it20:58
prometheanfireso, about your patch, I voted20:58
tonybdirk: but we ruled that out in Denver ... I don't recall why :/20:59
prometheanfireI think we are all ok with option 420:59
prometheanfirewhich is what his patch represents20:59
tonybdhellmann: I'm not sure that's the case20:59
dirktonyb: I'm certainly not able to recall that at this time of the day anymore either20:59
*** edmondsw has quit IRC20:59
tonybdhellmann: 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
dirkyeah, exactly21:00
dhellmanndirk : 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 there21:00
dirkmany of those subtleties in all the changes that we did are not clear to me21:00
tonybdhellmann: I *think* that's okay as the minimums in g-r were s'posed to represent the global minimums21:01
dhellmanntonyb : we already have projects that are like that and it causes no issues21:01
prometheanfiretonyb: individually no, I don't think it's a problem21:01
dhellmannI'm trying to enable 2 new cases21:01
prometheanfiretonyb: that's my understanding as well21:01
dhellmann1. Separate installations of a service without a bunch of newer dependencies21:01
dirkdhellmann: 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 projects21:01
dhellmann2. Stable libraries appearing stable because their requirements don't change automatically21:01
dhellmanndirk : 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 list21:02
dirkdhellmann: 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 env21:02
dhellmannbecause projects.txt includes *tons* of things in it that are probably irrelevant for your distribution21:02
dhellmannI agree, that's likely the case21:02
dhellmannwhether we track a set of values centrally or not won't change that21:03
dirkdhellmann: right, aiming a full global lower-constraints is too much. starting with a $set of projects and combining theirs lower-constrains might be better21:03
dirkbut I wonder how we would want to resolve conflict in a tool. so thats why you still end up maintaining a file21:03
tonybdhellmann: No, but the central lower-constraints.txt was supposed to make an integrated run "easy"21:03
dhellmannif 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 jobs21:04
dhellmannand we could make that a goal for stein or T21:04
prometheanfirewe should be figuring out what the highest global min is (if we care to) not prescribing what it is21:04
prometheanfireso removal makes sense to me21:04
dhellmanntonyb : it makes it slightly easier to run the job at the expense of making it much harder to fix the list when the job fails21:04
dhellmannwell, slightly harder21:04
tonybdhellmann: Yeah for me it was an acceptable level of pain ... but my setpint is probably off21:05
dirkdhellmann: 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 work21:06
dhellmannI'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 repo21:06
tonybanyway 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/requirements21:06
dirkyep, +121:06
tonybis that the simple take away?21:06
prometheanfireyes21:06
dirkexactly21:06
dirkone step at a time, we'll all be more wise tomorrow21:06
dhellmannyeah, 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
prometheanfirelol21:07
tonybdhellmann: ;P that's pretty much the std. disclaimer on IRC ;P21:07
dirkdhellmann: 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 listen21:07
dhellmannonce 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 runs21:08
dirk(doesn't have to be now)21:08
tonybokay so we did reach consensus.21:08
prometheanfireopen floor next?21:08
dhellmanndirk : I had to use https://review.openstack.org/#/c/558610/ to fix a bunch of the original lower-constraints.txt files in various repos21:08
dhellmannso I think the global lower-constraints file is a "highest min" but within each project I needed the *actual* min21:09
prometheanfire#topic open floor21:09
*** openstack changes topic to "open floor (Meeting topic: requirements)"21:10
dhellmannand if those are already different, then we've already drifted apart (yay!) but that means the global values are already not right21:10
dhellmannthank you all for hashing this out one more time21:10
dirkdhellmann: right, I agree the highest-min currently are also actually likely a bit higher then the actually lowest highest min21:10
* dhellmann is getting confused with the conflicting highest-lowest-highest qualifiers21:11
dhellmann:-)21:11
tonybdhellmann: Yeah it's always a problem ;P21:11
dirkyeah21:11
dirkthis is tricky21:11
dhellmannlowest-coinstallable-set?21:11
dirkyes21:11
prometheanfiredhellmann: took me a while to get used to21:11
dhellmannmaybe that's a better name then21:11
prometheanfirethe global highest min may not be co-installable21:12
prometheanfireproject-b may have a != on it or something21:12
tonyblowest-coinstallable-set-that-may-work-but-probably-not.txt ;P21:12
tonybor is that a little passive aggressive ?21:12
prometheanfiretonyb: yes, lets use that :D21:12
dhellmannprometheanfire : no, because we enforce that projects cannot exclude things that are not also excluded in the global list21:12
prometheanfireno, I like it :D21:12
prometheanfiredhellmann: true, so.. should be good21:12
dhellmanntonyb : just-dont-even-try-it.txt?21:12
dhellmannmaybe that's too aggressive :-)21:13
tonybdhellmann: #winner ;P21:13
prometheanfireanyone have any other topics before I close?21:13
dirkcan you remind us about other prios other than no req sync?21:13
dirkI've just seen that py36 patch that I neglected to followup21:13
prometheanfiredirk: what do you mean? other things to do this cycle?21:14
dirkyes21:14
dirkor upcoming things to worry about21:14
prometheanfireuncapping and py36 are the main things I guess21:14
tonybdirk: Yeah we need to sort out and test py36 this cycle21:14
dhellmannwe have https://review.openstack.org/#/q/topic:uncap-eventlet21:14
prometheanfireif you are working on p36 I can focus on uncapping eventlet21:14
prometheanfiredhellmann: ++21:14
prometheanfireanyone have anything else?21:15
dirkit looks liekt he cross job worked but neutron and some others failed on py3621:15
dirkwell, I guess finding-sensible-goal-for-dont-try-it-txt :-)21:16
tonybI'd like to work out if we can switch *constratints.txt to use <= and > in python_version markers21:16
dhellmannwhat are we doing with 3.6? that seems like a community-wide thing21:16
dirkproviding+generating a py36 compatible uc21:16
dhellmanntonyb : is that related to my hacky evaluation logic?21:16
prometheanfiretonyb: that's a nice to have thing imo21:16
tonybdhellmann: There are some aspects we need to nail down before the community can make meaningful progress21:16
dhellmanndirk : so we don't just assume what we have now works and let project teams tell us otherwise when their jobs fail?21:16
tonybdhellmann: partially but I really don't like that we basically have ==3.4 ; ==3.5 and ==3.621:17
dhellmannthe 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
dirkdhellmann: the principle of g-r so far was "we know it better than you" ;-)21:17
dirknow with the g-r sync disabled I guess we have to find a new mission21:18
tonybdhellmann: it's just wrong and we're basically making up thr 3.4 and 3.6 data anyway21:18
dirkdhellmann: the review I was talking about is https://review.openstack.org/#/c/554824/21:18
dhellmanntonyb : sure. maybe the thing to do is get the packaging library to expose the resolver in a better way so we can reuse it21:18
prometheanfiredirk: we record the wisdom of the masses :P21:18
dhellmannright now it assumes no one is going to pass environment values in, but we need to be able to do that21:18
dhellmanndirk : I think this team is too small and overworked to stick with that "we know better" policy :-/21:18
* dirk isn't that small21:18
tonybdhellmann: I'm not sure what we can get out of packaging to make this better21:19
tonybdhellmann: but if you have ideas I'm open21:19
* prometheanfire fits neatly into overhead bins21:19
dhellmannI 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 have21:19
prometheanfiredhellmann: that's a constant work in progress21:19
dhellmanntonyb : 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 us21:19
dirkdhellmann: yeah, dropping redundant/bad dependencies (e.g. not py3 comptible) would be a good goal to work on21:20
dirkif you're working for a distro then openstack is still a major pain21:20
dhellmannso 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
tonybdhellmann: 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 data21:20
dhellmannI think *many* people would appreciate reducing redundant dependencies as a goal. I'm not sure many developers would. :-)21:20
prometheanfiredhellmann++21:21
dirkdhellmann: usually noone minds if somebody else does the work..21:21
dhellmanntonyb : 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
dirkit 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 tech21:21
prometheanfirethat's what I'm finding with the cryptography migration...21:21
tonybdirk: that's partially true by $project now needs to grok as some level $new_lib instead of $old_lib and that's a pain point21:22
dhellmannthat 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 app21:22
dirktonyb: are we over complexifying the problem?21:22
tonybdirk: I don't think so21:23
dirktonyb: 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
dirkI m not sure many libs have conflicting dependencies for individual py3.x versions21:23
tonybdirk: I don't think that works.21:23
dirkok, tell me why?21:23
prometheanfireI 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
tonybdirk: It's not really about conflicting dependencies, it's about generating a constraints file that's valid and actually constrains things21:24
tonybdirk: And do you really want to start setting up meta reviews?21:25
dirkright, validity checks can be done in our existing check-uc job21:25
dhellmannwhy are we using == for several versions now instead of >='3.5'?21:25
tonybdhellmann: That's the root of the question21:25
dhellmannmaybe we should just change the list and see what we end up with21:26
tonybdhellmann: 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
dhellmannyeah21:26
dhellmannI suspect that when we switch to 3.6 we're not going to need to worry about supporting 3.5 any more21:27
prometheanfirewe can continue discussing this after the meeting, we are coming up on time21:27
dhellmannuntil we are off of 2.7 I don't see us supporting more than one version of 3.x21:27
dhellmannok21:27
tonybsplitting on <3.$x where $x would vary based on out CI environment (4 for xenial 6 for biaonic) is right21:27
tonybit's certainly simplier21:27
prometheanfiretonyb++21:27
tonybI guess we need to ask lifeless21:27
dhellmannwe don't need to support 3.4 though21:27
prometheanfirethat's my understanding as why we need multiple py3 versions as well21:27
dhellmannat least not on master21:28
prometheanfire#endmeeting21: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
openstackMeeting ended Wed Apr 11 21:28:09 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:28
openstackMinutes:        http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-04-11-20.29.html21:28
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-04-11-20.29.txt21:28
openstackLog:            http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-04-11-20.29.log.html21:28
tonybdhellmann: Yeah on $branch we'd have a minimum 3.4, 3.6 etc21:28
dhellmannwe've been trying to support multiple versions of 3 because we're still working our way fully onto 321:28
dhellmannwhen we do make it onto 3, I think we'll all be on 3.6 everywhere21:28
dhellmannand we can drop 3.x testing on older branches21:28
dhellmannno one is actually distributing things on 3 for older branches21:28
prometheanfiredhellmann: I agree that's likely21:28
dhellmannat least I hope not21:28
prometheanfireI package py3 versions of openstack21:29
prometheanfireI'm running py3 on my cluster at home21:29
prometheanfireiirc openstack ansible is using py3 for some things too21:29
dhellmannok21:29
dhellmannso we don't drop anything on old branches21:29
dhellmannbut we don't need to carry over the old 3.x versions on master21:29
prometheanfireack21:29
dirkits just a constraints file anyway?21:30
dirke.g. it contains massive amount of information in order to be as complete as possible21:30
tonybdhellmann: 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
dhellmannyeah21:30
dhellmannany day now21:30
prometheanfirelol21:30
tonyb:)21:31
dhellmannit's wine-o'clock here so I'm going to call it a day21:31
prometheanfireyep, I'm about to head home now too21:31
prometheanfirecatch you later21:31
smcginniso/21:31
dhellmanntonyb : I assume you'll vote on https://review.openstack.org/#/c/560108/ after you get the kids off to school?21:32
tonybdhellmann: done.  (the vote not the trip to school)21:35
tonyband with that I go AFK21:35
dhellmanntonyb : thanks21:36
*** cjloader_ has joined #openstack-requirements21:42
*** cjloader has quit IRC21:42
*** cjloader_ has quit IRC21:47
*** andreas_s has joined #openstack-requirements22: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:4522:30
*** andreas_s has quit IRC22:31
*** cjloader has joined #openstack-requirements22:32
jlvillaldhellmann, prometheanfire: I proposed https://review.openstack.org/#/c/560675/ so that we can fix gate for Ironic stable/pike.22:33
jlvillalBut 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 IRC22:37
prometheanfirejlvillal: I think I'm fine with adding to blacklist in a stable branch, I don't think we have a rule around it22:42
prometheanfiretonyb: ^22:42
jlvillalprometheanfire, thanks22:42
*** edmondsw has joined #openstack-requirements22:43
tonybjlvillal: Can you point me at a fialinf change and wht the fix in ironic looks like22:48
*** edmondsw has quit IRC22:48
jlvillaltonyb, What?  'fialinf'?22:48
tonybjlvillal: I'm kinda confused how pycodestyle is getting invloved in your linters on pike22:48
tonybjlvillal: *failing*22:48
tonybjlvillal: the commit message states that ironic is broken so surely you have a failing change22:49
prometheanfiretonyb: let me see if I can find the refrence, but a flake8-* lib is pulling it in (not flake8 itself)22:49
prometheanfiretonyb: https://github.com/openstack/ironic/blob/stable/pike/test-requirements.txt#L2222:50
jlvillaltonyb, I'm seeing errors like this: http://paste.openstack.org/show/718997/22:50
prometheanfirehttps://github.com/PyCQA/flake8-import-order/blob/0.11/setup.py#L3822:50
tonybOkay so https://review.openstack.org/#/c/560556/ is what I was looking for22:52
jlvillaltonyb, Ah! I thought you wanted an error showing the failing PEP8 errors.22:53
tonybjlvillal: I did, but that commit links to those errors, and the full .tox logs so I can work out what's going on22:53
jlvillaltonyb, The change you posted is the reason I proposed my patch https://review.openstack.org/#/c/560675/22:53
tonybjlvillal: adding it to the blacklist will mean that all projects that are affected have to fix it locally22:54
tonybjlvillal: it seems like we shoudl be able to do something smarter22:54
jlvillaltonyb, I'm confused? What projects have it listed?22:54
tonybprometheanfire: https://github.com/PyCQA/flake8-import-order/blob/0.11/setup.py#L32 is the relevant line22:55
jlvillaltonyb, I don't think 'pycodestyle' can be in any requirements.txt or test-requirements.txt because it isn't in global-requirements22:55
tonybjlvillal: If we add it to the blacklist all projects will have to do something like what you're doing in ironic which seems sub-optimal22:55
prometheanfiretonyb: yep, I just linked the first one I saw22:56
tonybjlvillal: Right so I think the right solution is to put it in g-r (and u-c) and ban the broken version22:56
tonybbut we need to think through that22:56
jlvillaltonyb, Okay. That sounds reasonable to me also. I'm not sure how many other projects are affected by this.22:57
tonybjlvillal: 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
jlvillaltonyb, Okay. Thanks!23:09

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!