20:29:59 <prometheanfire> #startmeeting requirements
20:30:00 <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:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:30:04 <openstack> The meeting name has been set to 'requirements'
20:30:07 <prometheanfire> so close
20:30:13 <dhellmann> o/
20:30:15 <prometheanfire> #topic Roll-call
20:30:20 <tonyb> \o
20:30:20 <prometheanfire> tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann
20:30:26 <dhellmann> \o
20:30:34 <prometheanfire> \o/
20:30:40 <dirk> o/
20:30:47 <tonyb> huzzah!
20:30:54 <dirk> dhellmann is in australia?
20:30:59 <dhellmann> eastern USA
20:31:01 <tonyb> it's 0630 and today is a success already :)
20:31:07 <prometheanfire> lol
20:31:17 * dhellmann will return with a beverage in 30 secs
20:31:20 <prometheanfire> k
20:31:28 <smcginnis> o/
20:31:35 <prometheanfire> #topic Any controversies in the Queue?
20:31:41 <prometheanfire> other than dougs item
20:31:47 <prometheanfire> we should probably discuss that separately
20:32:21 <smcginnis> Is Doug's item the OVO thing you just brought up?
20:32:26 <prometheanfire> no
20:32:34 <prometheanfire> that's not a controversy :P
20:32:55 <prometheanfire> https://review.openstack.org/558604
20:33:01 <prometheanfire> let's talk about that one
20:33:32 <tonyb> prometheanfire: sure
20:33:42 * dirk doesn't know the background of that one
20:33:49 <dhellmann> is 3.26.0 a queens version of oslo.concurrency?
20:33:50 <tonyb> prometheanfire: it's a policy violation
20:34:11 <dhellmann> it doesn't look like it
20:34:13 <dhellmann> https://releases.openstack.org/queens/index.html#queens-oslo-concurrency
20:34:36 <tonyb> dhellmann: no it's the first rocky release
20:34:58 <dhellmann> although that patch linked in the commit message is on queens
20:34:59 <prometheanfire> that's the only problem with it
20:35:16 <dhellmann> this is a security-related thing?
20:35:18 <prometheanfire> the problem the change aims to fix is a security related one
20:35:19 <prometheanfire> yes
20:35:22 <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:39 <dhellmann> did we release a new oslo.concurrency from queens?
20:35:50 <prometheanfire> dhellmann: a 3.25.1?
20:36:03 <dirk> yeah, thats my question as well - why aren't security fixes backported anymore to queens series?
20:36:03 <dhellmann> yeah, I guess that's what it would be
20:36:10 <dhellmann> the fix is backported
20:36:11 <prometheanfire> tonyb: so how do we exclude security fails from stable branches?
20:36:15 <dhellmann> they're just going about this wrong
20:36:26 <dhellmann> they need to release from queens and then update the constraint
20:36:40 <dhellmann> then they need to update their code to work if the parameter is not present
20:36:40 <prometheanfire> yes, that's the most optimal solution
20:36:40 <dirk> do we want to allow them to require the version with the security fix on the queens branch?
20:36:43 <tonyb> what dhellmann said
20:36:49 <dhellmann> 3 steps
20:37:01 <prometheanfire> tonyb: can we have !=3.25.0 while updating uc to 3.25.1 then?
20:37:05 <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:14 <dhellmann> why would we block the older release?
20:37:25 <prometheanfire> dhellmann: security is the only reason I have
20:37:42 <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:54 <smcginnis> Yeah, looks like prashkre was confused about how stable requirements are handles with that patch.
20:37:57 <dhellmann> yeah, we don't usually update mins for "bug fixes" regardless of the nature of the bug
20:38:13 <dirk> its an interesting test case for the requirements validator though
20:38:15 <dhellmann> right, I think this is just a matter of needing to educate folks about the right process to follow
20:38:17 <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:19 <dirk> it clearly misses that point
20:38:23 <tonyb> prometheanfire: we can look at, given this security related we make an exception but I'm not totally convinced this qualifies
20:38:34 <tonyb> prometheanfire: Nope we don't
20:38:42 <dhellmann> this is a logging security thing, right? not every deployment is going to need to worry about it.
20:38:47 * prometheanfire could have sworn that we did, but ok
20:38:59 <prometheanfire> dhellmann: true, the severity isn't the highest
20:39:04 <dhellmann> we allow the constraint to change but we don't try to force the use of the new version
20:39:28 <prometheanfire> I'm ok with that
20:39:30 <tonyb> prometheanfire: If we have done it then it's a human error
20:39:48 <prometheanfire> tonyb: k
20:39:50 <dhellmann> who's going to work with the cinder folks on this?
20:39:59 <prometheanfire> dhellmann: I'm making a comment now
20:40:13 <dhellmann> and bnemec to get that oslo release
20:40:35 <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:38 <dhellmann> I guess I'm the oslo release liaison, so I could just do that
20:40:51 <dhellmann> tonyb : they need to not assume it is there
20:41:00 <dhellmann> which probably means not a clean backport
20:41:13 <tonyb> I'm happy to propose the backport and release if bnemec and dhellmann are okay with it
20:41:33 <prometheanfire> commented
20:41:35 <dhellmann> sure, I can +1/+2 the release
20:41:50 <prometheanfire> next
20:41:51 <prometheanfire> https://review.openstack.org/555269
20:41:53 <tonyb> dhellmann: cool.  I'll post them today
20:41:58 <prometheanfire> can we just abandon that?
20:42:32 <tonyb> prometheanfire: Yup
20:42:50 <prometheanfire> done
20:42:55 <tonyb> prometheanfire: we don't add setuptools to u-c as manytimes it's a bootstrap problem
20:43:08 <prometheanfire> ya, I commented as such
20:43:17 <prometheanfire> now if only gertty would catch up
20:43:25 <tonyb> also newton is EOL so we're closed for business there
20:43:48 <prometheanfire> tonyb: this one's yours
20:43:49 <prometheanfire> https://review.openstack.org/551111
20:44:28 <tonyb> prometheanfire: Oh yeah I need to rebase it now the master version has mereged
20:44:38 <tonyb> I'll do that today
20:44:40 <prometheanfire> k
20:45:04 <prometheanfire> #topic remove lower bounds from global requirements
20:45:10 <prometheanfire> #link https://review.openstack.org/560108
20:45:14 <prometheanfire> dhellmann: you're up
20:45:21 <tonyb> also 55 11 11 is a cool change number ;P
20:45:32 <prometheanfire> tonyb: indeed
20:45:39 <prometheanfire> I was envious when I saw it
20:45:49 <tonyb> ahh small things :)
20:45:49 <dhellmann> right, so we're almost done with the changes to allow lower bound divergence and add lower-constraints tests
20:46:06 <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:11 <dhellmann> and different exclusions
20:46:22 <dhellmann> I'm trying to sync those up so we can get the lower-constraints job in place
20:46:36 <dhellmann> and as I point out in my comment on the bug, I see 4 options
20:46:45 <dhellmann> 1. Force projects to update their minimums. I include this for completeness, but think it's a terrible idea.
20:46:50 <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:55 <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:47:00 <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:12 <dhellmann> I went with the last option, because it felt like it made the most sense
20:47:38 <dhellmann> prometheanfire indicated that option 3 might be preferred, and I could live with that, but it's going to look weird
20:48:04 <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:07 <dirk> dhellmann: what do you mean by demonstratably wrong?
20:48:08 <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:33 <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:49:04 <prometheanfire> dhellmann: a patch doing option 3 would be intreresting to test though (just to see what breaks)
20:49:08 <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:10 <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:16 <dhellmann> dirk : yes, that's right
20:49:21 <dirk> dhellmann: but those older versions wouldn't be coinstallable
20:49:37 <dhellmann> dirk : maybe. I do not have a goal of making the lower bounds co-installable.
20:49:48 <dhellmann> and I think that is the source of a lot of the conflict and confusion over these changes
20:50:06 <dhellmann> I want the values in each project repo to be accurate. I don't care if they're the same.
20:50:31 <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: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:55 <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:59 <dhellmann> and I think trying to maintain a single central list does add too much friction
20:51:12 <dirk> are the projects running sensible tests against their in-project lower constraints? ike a functional test suite? or unit tests?
20:51:26 <dhellmann> for now most of them are just running unit tests
20:51:38 <dirk> are they all at least running unit tests?
20:51:48 <openstackgerrit> Matthew Thode proposed openstack/requirements master: Add swift exclusions  https://review.openstack.org/560636
20:51:58 <tonyb> dirk: unit tests but it's totally doable to add funcational tests
20:52:19 <dhellmann> some are. not all have landed the job. not all of the jobs are working
20:52:24 <dhellmann> https://review.openstack.org/#/q/status:open++topic:requirements-stop-syncing
20:52:43 <dhellmann> most of the major projects have added the unit test job
20:53:22 <prometheanfire> distros don't care that openstack is co-installable for the lower version if they have multiple versions available to install
20:53:36 <prometheanfire> distros should install what is co-installable if they can (dep solving is there for a reason)
20:53:43 <prometheanfire> at least that's my perspective from gentoo
20:53:49 <tonyb> prometheanfire: I'm not sure that's dirk's POV with hsi distro hat on
20:53:52 <dhellmann> right, I suspect we could have a different set of co-installable versions from each vendor.
20:53:57 <prometheanfire> ya, that's why I said gentoo :p
20:54:13 <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:27 <dirk> prometheanfire: in almost all cases the uc version isn't available yet due to $reasons
20:54:34 <dirk> because uc updates within hours of the upstream release
20:54:37 <dhellmann> this is an area where we could completely consume all community testing resources (human and bot) to satisfy this need
20:54:56 <dhellmann> and I don't think the *community* benefit warrants doing that
20:55:07 <prometheanfire> dhellmann: agreed (Openstack isn't responsible for disto testing)
20:55:20 <dhellmann> I also don't think these changes make that work any harder
20:55:28 <dirk> I agree to the latter part
20:55:40 <dirk> removing the lower bounds from g-r.txt doesn't change anything in that area
20:55:51 <tonyb> dirk: really?
20:56:06 <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:28 <tonyb> dirk: I thought you wanted to maintain a global-maximum list of minimums
20:56:31 <dhellmann> and *that* set would be (a) accurate and (b) targeted to the projects being packaged
20:56:38 <dirk> tonyb: what am I missing? remember it is very late here and I had a very long and stressful day :)
20:56:43 <tonyb> and removeing the minimums from g-r makes that *much* harder
20:56:54 <dhellmann> tonyb : no, it doesn't, because those numbers are *already wrong*
20:56:59 <prometheanfire> dhellmann: that's what I've been wanting to track in a separate file
20:57:04 <prometheanfire> pull vs push the min
20:57:13 <dirk> tonyb: but those numbers are tracked in the lower-constraints.txt in the requirements repo already?
20:57:14 <prometheanfire> but that's a separate project
20:57:17 <dhellmann> I'm not sure why we need to check the results of that file in, but ok
20:57:18 <dirk> right now they're just duplicated
20:57:22 <dhellmann> dirk : exactly
20:57:51 <dirk> dhellmann: we could generate it from the sum of projects indeed
20:57:58 <tonyb> dhellmann: Yes they're wrong I don't deny that
20:58:09 <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:16 <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:31 <tonyb> dhellmann: but that's ok while we fix them Stien+ if we set expectations
20:58:32 <dhellmann> prometheanfire : sure
20:58:50 <dhellmann> tonyb : the "fix" is going to be to lower a bunch of values. Are you ok with that?
20:58:53 <tonyb> dirk: If you're okay with that outcome then I'm fine with it
20:58:58 <prometheanfire> so, about your patch, I voted
20:59:12 <tonyb> dirk: but we ruled that out in Denver ... I don't recall why :/
20:59:23 <prometheanfire> I think we are all ok with option 4
20:59:31 <prometheanfire> which is what his patch represents
20:59:34 <tonyb> dhellmann: I'm not sure that's the case
20:59:44 <dirk> tonyb: I'm certainly not able to recall that at this time of the day anymore either
21:00:25 <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:44 <dirk> yeah, exactly
21:00:45 <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:55 <dirk> many of those subtleties in all the changes that we did are not clear to me
21:01:01 <tonyb> dhellmann: I *think* that's okay as the minimums in g-r were s'posed to represent the global minimums
21:01:02 <dhellmann> tonyb : we already have projects that are like that and it causes no issues
21:01:03 <prometheanfire> tonyb: individually no, I don't think it's a problem
21:01:21 <dhellmann> I'm trying to enable 2 new cases
21:01:25 <prometheanfire> tonyb: that's my understanding as well
21:01:35 <dhellmann> 1. Separate installations of a service without a bunch of newer dependencies
21:01:47 <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:48 <dhellmann> 2. Stable libraries appearing stable because their requirements don't change automatically
21:02:20 <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:31 <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:36 <dhellmann> because projects.txt includes *tons* of things in it that are probably irrelevant for your distribution
21:02:48 <dhellmann> I agree, that's likely the case
21:03:20 <dhellmann> whether we track a set of values centrally or not won't change that
21:03:40 <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:54 <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:54 <tonyb> dhellmann: No, but the central lower-constraints.txt was supposed to make an integrated run "easy"
21:04:00 <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:08 <dhellmann> and we could make that a goal for stein or T
21:04:15 <prometheanfire> we should be figuring out what the highest global min is (if we care to) not prescribing what it is
21:04:22 <prometheanfire> so removal makes sense to me
21:04:33 <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:41 <dhellmann> well, slightly harder
21:05:26 <tonyb> dhellmann: Yeah for me it was an acceptable level of pain ... but my setpint is probably off
21:06:07 <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:10 <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:10 <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:26 <dirk> yep, +1
21:06:26 <tonyb> is that the simple take away?
21:06:30 <prometheanfire> yes
21:06:33 <dirk> exactly
21:06:42 <dirk> one step at a time, we'll all be more wise tomorrow
21:06:51 <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:07:00 <prometheanfire> lol
21:07:43 <tonyb> dhellmann: ;P that's pretty much the std. disclaimer on IRC ;P
21:07:47 <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:08:12 <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:15 <dirk> (doesn't have to be now)
21:08:17 <tonyb> okay so we did reach consensus.
21:08:31 <prometheanfire> open floor next?
21:08:49 <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:09:33 <dhellmann> so I think the global lower-constraints file is a "highest min" but within each project I needed the *actual* min
21:09:59 <prometheanfire> #topic open floor
21:10:02 <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:12 <dhellmann> thank you all for hashing this out one more time
21:10:26 <dirk> dhellmann: right, I agree the highest-min currently are also actually likely a bit higher then the actually lowest highest min
21:11:00 * dhellmann is getting confused with the conflicting highest-lowest-highest qualifiers
21:11:02 <dhellmann> :-)
21:11:15 <tonyb> dhellmann: Yeah it's always a problem ;P
21:11:15 <dirk> yeah
21:11:18 <dirk> this is tricky
21:11:29 <dhellmann> lowest-coinstallable-set?
21:11:41 <dirk> yes
21:11:44 <prometheanfire> dhellmann: took me a while to get used to
21:11:52 <dhellmann> maybe that's a better name then
21:12:00 <prometheanfire> the global highest min may not be co-installable
21:12:18 <prometheanfire> project-b may have a != on it or something
21:12:24 <tonyb> lowest-coinstallable-set-that-may-work-but-probably-not.txt ;P
21:12:32 <tonyb> or is that a little passive aggressive ?
21:12:34 <prometheanfire> tonyb: yes, lets use that :D
21:12:38 <dhellmann> prometheanfire : no, because we enforce that projects cannot exclude things that are not also excluded in the global list
21:12:39 <prometheanfire> no, I like it :D
21:12:50 <prometheanfire> dhellmann: true, so.. should be good
21:12:54 <dhellmann> tonyb : just-dont-even-try-it.txt?
21:13:06 <dhellmann> maybe that's too aggressive :-)
21:13:10 <tonyb> dhellmann: #winner ;P
21:13:19 <prometheanfire> anyone have any other topics before I close?
21:13:42 <dirk> can you remind us about other prios other than no req sync?
21:13:58 <dirk> I've just seen that py36 patch that I neglected to followup
21:14:12 <prometheanfire> dirk: what do you mean? other things to do this cycle?
21:14:19 <dirk> yes
21:14:27 <dirk> or upcoming things to worry about
21:14:33 <prometheanfire> uncapping and py36 are the main things I guess
21:14:41 <tonyb> dirk: Yeah we need to sort out and test py36 this cycle
21:14:42 <dhellmann> we have https://review.openstack.org/#/q/topic:uncap-eventlet
21:14:45 <prometheanfire> if you are working on p36 I can focus on uncapping eventlet
21:14:48 <prometheanfire> dhellmann: ++
21:15:44 <prometheanfire> anyone have anything else?
21:15:45 <dirk> it looks liekt he cross job worked but neutron and some others failed on py36
21:16:04 <dirk> well, I guess finding-sensible-goal-for-dont-try-it-txt :-)
21:16:05 <tonyb> I'd like to work out if we can switch *constratints.txt to use <= and > in python_version markers
21:16:13 <dhellmann> what are we doing with 3.6? that seems like a community-wide thing
21:16:37 <dirk> providing+generating a py36 compatible uc
21:16:40 <dhellmann> tonyb : is that related to my hacky evaluation logic?
21:16:54 <prometheanfire> tonyb: that's a nice to have thing imo
21:16:58 <tonyb> dhellmann: There are some aspects we need to nail down before the community can make meaningful progress
21:16:59 <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:17:42 <tonyb> dhellmann: partially but I really don't like that we basically have ==3.4 ; ==3.5 and ==3.6
21:17:43 <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:49 <dirk> dhellmann: the principle of g-r so far was "we know it better than you" ;-)
21:18:01 <dirk> now with the g-r sync disabled I guess we have to find a new mission
21:18:06 <tonyb> dhellmann: it's just wrong and we're basically making up thr 3.4 and 3.6 data anyway
21:18:08 <dirk> dhellmann: the review I was talking about is https://review.openstack.org/#/c/554824/
21:18:11 <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:23 <prometheanfire> dirk: we record the wisdom of the masses :P
21:18:24 <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:45 <dhellmann> dirk : I think this team is too small and overworked to stick with that "we know better" policy :-/
21:18:59 * dirk isn't that small
21:19:05 <tonyb> dhellmann: I'm not sure what we can get out of packaging to make this better
21:19:17 <tonyb> dhellmann: but if you have ideas I'm open
21:19:19 * prometheanfire fits neatly into overhead bins
21:19:28 <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:45 <prometheanfire> dhellmann: that's a constant work in progress
21:19:58 <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:20:06 <dirk> dhellmann: yeah, dropping redundant/bad dependencies (e.g. not py3 comptible) would be a good goal to work on
21:20:16 <dirk> if you're working for a distro then openstack is still a major pain
21:20:21 <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:47 <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:48 <dhellmann> I think *many* people would appreciate reducing redundant dependencies as a goal. I'm not sure many developers would. :-)
21:21:03 <prometheanfire> dhellmann++
21:21:29 <dirk> dhellmann: usually noone minds if somebody else does the work..
21:21:40 <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:48 <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:50 <prometheanfire> that's what I'm finding with the cryptography migration...
21:22:10 <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:33 <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:53 <dirk> tonyb: are we over complexifying the problem?
21:23:07 <tonyb> dirk: I don't think so
21:23:15 <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:43 <dirk> I m not sure many libs have conflicting dependencies for individual py3.x versions
21:23:47 <tonyb> dirk: I don't think that works.
21:23:57 <dirk> ok, tell me why?
21:24:25 <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:37 <tonyb> dirk: It's not really about conflicting dependencies, it's about generating a constraints file that's valid and actually constrains things
21:25:06 <tonyb> dirk: And do you really want to start setting up meta reviews?
21:25:06 <dirk> right, validity checks can be done in our existing check-uc job
21:25:14 <dhellmann> why are we using == for several versions now instead of >='3.5'?
21:25:33 <tonyb> dhellmann: That's the root of the question
21:26:12 <dhellmann> maybe we should just change the list and see what we end up with
21:26:28 <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:38 <dhellmann> yeah
21:27:08 <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:15 <prometheanfire> we can continue discussing this after the meeting, we are coming up on time
21:27:18 <dhellmann> until we are off of 2.7 I don't see us supporting more than one version of 3.x
21:27:23 <dhellmann> ok
21:27:30 <tonyb> splitting on <3.$x where $x would vary based on out CI environment (4 for xenial 6 for biaonic) is right
21:27:41 <tonyb> it's certainly simplier
21:27:45 <prometheanfire> tonyb++
21:27:48 <tonyb> I guess we need to ask lifeless
21:27:57 <dhellmann> we don't need to support 3.4 though
21:27:59 <prometheanfire> that's my understanding as why we need multiple py3 versions as well
21:28:07 <dhellmann> at least not on master
21:28:09 <prometheanfire> #endmeeting