20:30:17 <prometheanfire> #startmeeting requirements
20:30:17 <openstack> Meeting started Wed Apr 18 20:30:17 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:30:18 * tonyb think's y'all are mostly tea drinkers anyway.
20:30:20 <openstack> The meeting name has been set to 'requirements'
20:30:30 <prometheanfire> tonyb: eh, I do both
20:30:35 <prometheanfire> #topic rollcall
20:30:37 <prometheanfire> o/
20:30:38 <tonyb> o/
20:30:42 <prometheanfire> tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann
20:30:46 <tonyb> or perhaps o7
20:30:58 <dhellmann> o/
20:31:34 <prometheanfire> o7 cmdr
20:31:37 <smcginnis> o/
20:32:08 <tonyb> I think this is probably all we'll get
20:32:15 <prometheanfire> #topic Any controversies in the Queue?
20:33:04 <prometheanfire> I don't think so, just gate breakages
20:33:12 <smcginnis> Nothing I'm aware of.
20:33:31 <prometheanfire> #topic gate breakage
20:33:55 <prometheanfire> I haven't had time to look at the libvirt_python build failure
20:34:17 <prometheanfire> I manually ran generate constraints locally and it worked (gentoo), the review is here https://review.openstack.org/562351
20:34:27 <prometheanfire> that's next on my todo list though
20:34:37 <prometheanfire> dhellmann: you know more about the other gate failure?
20:35:04 <tonyb> prometheanfire: You need to run it on xenial as it's a problem with the libvirt-python package interacting witht libvirt{.so,.h}
20:35:45 <dhellmann> other?
20:35:47 <tonyb> prometheanfire: I'll try to build a xenial machine at home today if I can get make progress on the stable gate :(
20:35:56 <dhellmann> oh, the thing jroll posted about?
20:36:17 * tonyb hasn't see that
20:36:31 <jroll> oh hi :)
20:36:33 <jroll> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129504.html
20:36:44 <prometheanfire> tonyb: sure, oldest libvirt I can use is 4.1.0-r3
20:37:09 <dhellmann> I just noticed the version of pbr was older there and stephenfin took out some of the magic setuptools stuff and thought upgrading pbr might help
20:37:42 <tonyb> prometheanfire: I don't think that's the point.  I bisected it down to the run it broke on so somethign chnage either in ubuntu/ our image (or both) in that 24 hours window
20:37:44 <jroll> dhellmann: yeah, just saw your reply. it would probably handle it, though I'd still be super confused to what the root cause is
20:37:52 <tonyb> my gut tells me it's the former
20:38:10 <tonyb> jroll: Yeah I'm looking at that and related failures on the stable branches
20:38:21 <tonyb> it's been a while since we had such a firedrill ;P
20:39:17 <jroll> tonyb: cool, thanks for looking into it. I've pretty much given up at this point :/
20:40:19 <tonyb> jroll: I think the bottom line is it's my problem and it affects lots of teams although your pep8 issue looks strange
20:40:58 <jroll> tonyb: I'm happy to help if you make headway, I'm just stuck
20:41:04 <jroll> don't want to put it all on you
20:41:20 <tonyb> jroll: cool, If I come up with seomthing I'll let you know
20:41:25 <jroll> <3
20:41:47 <prometheanfire> anyone have anything else?
20:42:07 * tonyb wonders if it's a pip10 thing
20:42:08 <dhellmann> I have another topic but it's not about the gate breakage
20:42:14 <prometheanfire> #topic Open Discussion
20:42:16 <prometheanfire> dhellmann: go ahead
20:42:48 <smcginnis> Sorry, I distracted him on a release thing.
20:42:55 <dhellmann> I was going to start working on the releases site support for different stable branch status per deliverables
20:42:57 <dhellmann> https://storyboard.openstack.org/#!/story/2001852
20:43:15 <dhellmann> I think tonyb had some ideas for what that needed to support, and I thought other folks in here might, too
20:43:23 <dhellmann> it's not really requirements related but since you're all here...
20:43:51 <dhellmann> just drop by that story and leave some comments when you have time
20:44:13 <tonyb> dhellmann: Oh cool, I don't think there's a lot to it
20:44:15 <prometheanfire> ok
20:44:16 <prometheanfire> :D
20:44:47 <tonyb> dhellmann: 1) Make sure updateing old deliverable files doesn't re-create EOLd branches
20:45:26 <dhellmann> noted
20:45:40 <tonyb> dhellmann: then make verything <=newton EOL, but setting a stable-status (name open for discussion) flag in each file and then 'maintained' for the rest
20:46:09 <tonyb> dhellmann: then update sphinx extension to display that and/or defult to maintained if missing
20:46:54 <tonyb> dhellmann: the thing I wanted to talk to operators/vendors about in YVR is given that do we need a single page per branch that lists the status of each deliverable in that release
20:47:09 <tonyb> to avoid havening to click a million links to find out what works
20:47:43 <dhellmann> yeah, I was going to show that info on the releases.o.o page for the series
20:48:03 <dhellmann> for example, in https://releases.openstack.org/queens/index.html#service-projects
20:48:09 <dhellmann> add a new column to the table
20:48:38 <tonyb> dhellmann: awesome that works nicely, then we can really simplify the table on the index.html
20:49:07 * dhellmann nods
20:49:21 <tonyb> anyone else have thoughts?
20:49:21 <dhellmann> do we want to show the default status for a branch on the main page?
20:49:36 <tonyb> dhellmann: I don't think so
20:49:39 <dhellmann> do we even want a default status for a branch?
20:49:43 <dhellmann> I thought we might, but maybe not
20:49:51 <tonyb> dhellmann: but I don't have a stronge feeling there
20:50:13 <dhellmann> ok, I'll see what looks easy to implement
20:50:56 <tonyb> dhellmann: Yeah I thought so.  Thanks for doing it. let me knwo if you want help or do a 'follow-the-sun' agiley thing ;P
20:51:13 <dhellmann> sure :-)
20:51:49 <prometheanfire> the only question I had is when we'll know when/where the next ptg is
20:52:00 <tonyb> I had a quesrion about per-project requirements ....
20:52:06 <prometheanfire> tonyb: sure
20:52:07 <dhellmann> prometheanfire : probably in vancouver
20:52:17 <prometheanfire> ah, makes sense
20:52:36 <tonyb> dhellmann: Oh that's not what I heard but things change quickly
20:52:39 <dhellmann> I think we have a strong sense that it's september and in north america, but we don't have more detail than that yet
20:52:51 <dhellmann> tonyb : we would *know* in vancouver
20:52:59 <dhellmann> sorry, I wasn't clear
20:53:09 <tonyb> dhellmann: Oh yeah that's more what I thought
20:53:26 <dhellmann> I anticipate an announcement around the summit
20:53:36 <tonyb> dhellmann: it was a perfectly correct response to the question on the table
20:54:12 <smcginnis> I heard "central US", but that's about it.
20:54:21 * prometheanfire isn't going to the summit
20:54:22 <smcginnis> Someone from the foundation told me it will be announced Friday.
20:54:28 * dhellmann gets out a map and a ruler
20:54:32 <smcginnis> prometheanfire: boo
20:54:35 <dhellmann> oh, nice, that's sooner than I expected
20:54:56 <dhellmann> prometheanfire: double boo
20:54:58 <tonyb> so with the per-project requirements stuff.  a project can only add a !=$version if it matches g-r right? but they don't have to have all the !='s in g-r
20:55:07 <dhellmann> tonyb : yes, that is correct
20:55:21 <prometheanfire> it was either that or germany, and I'd like to go to germany :D
20:55:32 <tonyb> do we have anything that stops a project from upping the minium version of a library?
20:55:35 <dhellmann> prometheanfire : I think I would have made the same decision in your position :-)
20:55:43 <tonyb> prometheanfire: Berlin summit!
20:55:51 <dhellmann> tonyb : the upper-constraints.txt entry must be compatible with the requirement entry in the project tree
20:56:02 <dhellmann> so they have to raise that first, and then they can raise the minimum version
20:56:22 <prometheanfire> they have to raise their requirements as well
20:56:30 <prometheanfire> and it cannot conflict with exclusions in gr
20:56:32 * dhellmann refers tonyb to the shiny new documentation at https://docs.openstack.org/project-team-guide/dependency-management.html#update-processes
20:56:48 <dhellmann> hmm, that's an interesting one
20:57:13 <tonyb> dhellmann: Well that's upper but say u-c had foo===3.0 and in $prject that had l-c==1.0 and requirements: foo>=1.0
20:57:14 <dhellmann> I'm not sure we have anything that prevents someone from setting the minimum in their tree from being a value excluded in the global lists
20:57:23 <tonyb> dhellmann: what stops them from ....
20:57:28 <tonyb> dhellmann: Well that's upper but say u-c had foo===3.0 and in $prject that had l-c==2.0 and requirements: foo>=2.0
20:57:32 <dhellmann> I mean it wouldn't work for u-c but it might as a lower bounds
20:57:39 <tonyb> part way through a release?
20:58:21 <dhellmann> tonyb : let me restate that and see if I understand what you're asking
20:58:35 <prometheanfire> dhellmann: hmm, exclusions should be synced to requirements still?
20:58:42 <tonyb> dhellmann: I'm not sure we need to do that thing ' setting the minimum in their tree from being a value excluded in the global lists'
20:58:44 <prometheanfire> of so that'd prevent them being set in lc
20:58:55 <tonyb> dhellmann: please do I'll be quiet
20:59:19 <dhellmann> are you concerned that a project could raise the minimum version of a dependency in the middle of a cycle?
20:59:46 <tonyb> dhellmann: Yes
21:00:09 <tonyb> dhellmann: with the centralised system we enforced that as part of the stable policy
21:00:11 <dhellmann> ok. we supported that already, and we need to still support it, right? otherwise we can't have nova depend on a new feature of oslo.messaging
21:00:16 <dhellmann> oh, in a *stable* branch
21:00:21 <tonyb> dhellmann: and I think we missed that in this design
21:00:24 <dhellmann> did we have automation in place for that?
21:00:40 <tonyb> dhellmann: yeah, sorry I though I said that but didn't
21:01:00 <dhellmann> we probably want to add an explicit check for that
21:01:03 <tonyb> dhellmann: No it was just really easy to spot and was explicit in the review guidlines
21:01:27 <dhellmann> I guess before we got it as a side-effect of requiring the exact match
21:01:39 <tonyb> dhellmann: Yeah more or less
21:01:46 <dhellmann> yeah, so that's a hole now, you're right
21:02:16 <dhellmann> prometheanfire : do you have a todo list somewhere that we should add that to?
21:02:29 <tonyb> dhellmann: Okay I'll look at adding it to the requirements-check tool/job
21:02:29 <dhellmann> in the mean time we can watch for it when we do stable release reviews
21:02:37 <dhellmann> ++
21:02:49 <prometheanfire> dhellmann: nope, a bug should be made
21:02:52 <dhellmann> we need to be careful that that rule is only applied to stable branches
21:03:03 <tonyb> dhellmann: Yeah as we don't have stable/rocky we don't have a problem
21:03:20 <dhellmann> well, someone could go change one of the existing stable branches now
21:03:38 <tonyb> dhellmann: it was just something I thought I noticed a coupel of days ago
21:03:49 <dhellmann> yeah, you're right, we should address that
21:04:11 <prometheanfire> question 1: should we allow projects to have a lc set to a version excluded in gr?
21:04:14 <tonyb> dhellmann: Oh yeah phooey I'll do it after the stable gate is fixed or at least I know how to fix it
21:04:34 <prometheanfire> question 2: do we sync exclusions from gr to project's reqs?
21:04:43 <tonyb> prometheanfire: no
21:05:04 <dhellmann> prometheanfire : no. there is currently no syncing of anything in any direction.
21:05:06 <prometheanfire> if question 2 is yes, then question 1 is moot
21:05:23 <tonyb> prometheanfire: part of the point is that $project doesn't have to care that $other_project has a problem witha specific version of $library they share
21:05:24 <dhellmann> answer 1 I think is yes
21:05:42 <tonyb> prometheanfire: as long as it isn't the current one in u-c
21:05:44 <prometheanfire> tonyb: sure, I just want thing spoken out
21:06:27 <tonyb> Sorry I was answering q2
21:06:38 <prometheanfire> I think I'm fine with saying yes to 1 as well
21:06:43 <tonyb> I think q1: yes, q2: no
21:06:44 <dhellmann> I don't think there is anything in place today to prevent a project from having a lower constraint set to a value that is excluded in the global list
21:06:48 <prometheanfire> as long as we are all clear on that we are good
21:06:51 <prometheanfire> tonyb++
21:07:21 <prometheanfire> dhellmann: the question is if that's a gap, I don't think it is, since uc are what's truely co-installable
21:08:26 <dhellmann> prometheanfire : right, I think we can ignore that or allow it or however you want to look at it
21:08:49 <prometheanfire> dhellmann: currently those are the same :P
21:08:54 <prometheanfire> just wanted policy to be clear
21:08:55 <dhellmann> we could spell that out, but I think it's going to be easier for people to understand the rules if we focus on "the upper-constraints value must be compatible with your requirements range"
21:09:36 <tonyb> I think it's a design feature, we only really care for the global-maxiumum-minium value and we dont'' track that yet so whoever writes those tools can care about it
21:09:59 <dhellmann> we came up with a better name for that last week, didn't we?
21:10:01 * dhellmann can't remember
21:10:06 <prometheanfire> lol, probably
21:10:16 <prometheanfire> ok, I think I'm done
21:10:19 <prometheanfire> anyone else have something?
21:10:34 <tonyb> dhellmann: Yeah I think it was dont-even-try.txt ;P
21:10:55 <dhellmann> we can call it the tjmaxx : https://www.youtube.com/watch?v=E9DzuisWI-I
21:11:00 <prometheanfire> tonyb: oh ya
21:11:07 <dhellmann> "the max for the minimum"
21:11:23 <prometheanfire> dhellmann: local maximum
21:11:37 <tonyb> prometheanfire: no local is per-project
21:11:47 <prometheanfire> https://www.wikiwand.com/en/False_vacuum
21:11:51 <prometheanfire> close to that concept
21:12:31 <prometheanfire> anyway, ending
21:12:34 <prometheanfire> #endmeeting