10:02:20 <tonyb> #startmeeting requirements
10:02:21 <openstack> Meeting started Wed Nov 16 10:02:20 2016 UTC and is due to finish in 60 minutes.  The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:02:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
10:02:24 <openstack> The meeting name has been set to 'requirements'
10:02:30 <toabctl> hi
10:02:35 <tonyb> #topic roll call try 2 :p
10:02:36 <coolsvap> o/
10:03:49 <tonyb> So we have dirk, coolsvap, toabctl ... anyone else?
10:03:56 <dirk> o/
10:04:22 <dirk> tonyb obviously :)
10:04:34 <tonyb> #topic Any controversies in the Queue?
10:05:00 * tonyb admit's he's been behind on reviews ... so anything?
10:05:03 <dirk> the unicorn?
10:05:24 <dirk> things are mostly good right now except for some fallout with the new ocata releases
10:05:37 <number80> o/
10:06:48 <tonyb> hey number80
10:07:53 <dirk> tonyb: haven't had a chance to process your feedback on the gunicorn change..
10:08:01 <dirk> #link https://review.openstack.org/#/c/386790/
10:08:52 <dirk> ah, there was a question and an answer
10:09:06 <tonyb> dirk: yeah gunicorn ... I need to get back to Adam, ... It's been hard (for me) to keep the conversation flowing
10:09:35 <dirk> my +2 is a just a "meh, don't care". I don't feel emotional enough about it either way
10:10:00 <tonyb> dirk: yeah fair enough.
10:11:40 <tonyb> dirk: I'd like to thank you again for the persistent work on getting all the constraints changes in.
10:11:41 <dirk> tonyb: take an action item and move on?
10:12:17 <tonyb> #topic Requirements priorities for Ocata
10:12:44 <tonyb> So I still haven't written up the plan
10:12:54 <dirk> tonyb: welcome.. eventually I might get around fixing the proposal bot, that it suggests duplicate updates is annoying
10:13:32 <tonyb> dirk: in what way are they duplicates?  ... duplicates of the ones the new-release bot generates?
10:16:06 <tonyb> okay So WRT to the grand plan we started an etherpad to track constraints support.  I've lost that link
10:16:19 <dirk> tonyb: yep, I always have to remove those that are already in separate reviews (and stuck there due to regressions)
10:16:43 <dirk> I know it probably requires a bit of magic. dunno how the magic will look like though
10:17:21 * coolsvap searching for the link of ehterpad
10:17:22 <dirk> probably patch -R's of all open reviews that touch uc on the same branch or something like that
10:17:27 <tonyb> dirk: Yeah it'd be quite tricky
10:18:46 <dirk> maybe this one ? https://etherpad.openstack.org/p/ocata-requirements-notes
10:19:21 <tonyb> dirk: Yeah that might work.  It *should* get easier during this cycle as the release team will chnage the bots so that the updates are one per chnage in the release repo as opposed to one per library
10:19:52 <tonyb> dirk: Thanks. the link I'm thinking of was speciifcally for constratints ...
10:20:13 <coolsvap> https://etherpad.openstack.org/p/requirements-track-constraints-usage
10:20:27 <tonyb> coolsvap: Yes!
10:20:40 <dirk> #link https://etherpad.openstack.org/p/requirements-track-constraints-usage
10:21:17 <tonyb> So the grand plan requires that all projects support constratints so we need to work with the team that don'tto get that support landed.
10:21:46 <tonyb> I'm working on a "template" in oslo.messaging that should roll out to all the others
10:22:04 <dirk> great, add the link to the review when ready so that we can copy it
10:22:08 <tonyb> Once the oslo.messaging one lands we can divide up the rest
10:22:28 <tonyb> #link https://review.openstack.org/#/c/394721/
10:23:02 <tonyb> It's WiP as it was blocked on the release of 1.0.0 of openstak-requirements ... which happened yesterday
10:23:21 <tonyb> That'll simlyfy the tox_install.sh script
10:23:23 <dirk> congrats :)
10:24:03 <tonyb> dirk: :) Standing on the shoulders of giants ;P
10:25:35 <tonyb> ... Once we have constrainst support we;ll be able to work towards removing minimum values into the projects and out of g-r.txt
10:25:58 * dirk still feels that the removal of a consistently enforced lower boundary will quickly turn the openstack* projects lower boundaries to become stale
10:26:03 <tonyb> then we'll be able to remove the proposal-bot altogether
10:26:28 <tonyb> dirk: we wont *have* any "openstck lower bound"
10:26:44 <dirk> well, individual lower bounds
10:26:54 <dirk> or do we plan to add a job to each project to verify that lower bounds still pass checks?
10:27:30 <dirk> my feeling is that as a downstream distro we'll not always be able to match uc exactly, and we're then outside waters
10:27:45 <dirk> if there is a range of [lc,uc) and we're in that one then I feel at least somewhat safe
10:27:51 <dirk> might be a stale feeling though
10:28:09 <dirk> outside safe waters I mean
10:28:10 <tonyb> dirk: Yes that one.  We'll write the tools to enable projects to test lower bounds either on each change to as a periodica job
10:28:17 <tonyb> the former would be preferred.
10:29:04 <tonyb> There was an idea that we'd only enble that on pyton3 only but I'm not a big fan of that
10:29:37 <dirk> ok, so uc is the globally enforced lockstep of coinstallability and centrally managed, and every project can choose their lc (but not their uc) ?
10:29:48 <coolsvap> yeah i think it can be part of the initial job template
10:29:50 <tonyb> COrrect
10:29:50 <dirk> sorry, with lc I mean lower bounds
10:31:16 <tonyb> And the theory is that the lower bounds stuff will always be "current" per project
10:31:29 <dirk> hmm. still feels that we're missing something, but I can't find the words for it right now
10:32:00 <tonyb> I helps with testing but I'm not 100% certain that it makes packagers lives easier ... I dont' think it makes it any harder
10:32:29 <tonyb> dirk: If you put you finger on it you know where I am ...
10:33:04 <tonyb> coolsvap, number80, toabctl: did that make sense to y'all?
10:33:27 <coolsvap> tonyb: yes agreed
10:33:38 <dirk> tonyb: how do projects get the uc? do they fetch it from git? or is it part of the pip installed package?
10:33:44 <dirk> the uc data itself I mean
10:34:06 <tonyb> dirk: the same way the do now ... they point to the cgit url
10:34:10 <dirk> ok
10:35:02 <tonyb> It does mean more testing in each project but we can't get better testing coverage without adding extra tests
10:35:26 <dirk> yeah, the uc changes in global-requirements will need more coverage tests.. but more is better anyway
10:36:08 <tonyb> dirk: Yeah.  We need to be careful there
10:38:09 <tonyb> okay so in terms of actions
10:38:28 <tonyb> #action tonyb to finish the oslo.messaging change
10:38:44 <tonyb> #action .... generate a list of projecst that need constaraints suppoer
10:38:55 <tonyb> #action .... land that support
10:39:17 <tonyb> By then we'll have the rest documented
10:39:21 <number80> yes
10:39:31 <tonyb> #topic Open Discussion
10:39:44 <tonyb> ... So 'sup?
10:39:50 <tonyb> Anythong to discuss here
10:40:41 <coolsvap> I have change to look at https://review.openstack.org/#/c/397532/
10:41:01 <coolsvap> its not controversial so brought up here
10:41:11 <tonyb> coolsvap: Thanks.
10:41:32 <tonyb> coolsvap: I had a quick look and the project-config chnage hadn't merged
10:41:51 <tonyb> coolsvap: I think we can all look at it today/tomorrow
10:42:14 <coolsvap> tonyb: its merged https://review.openstack.org/#/c/396903/
10:42:18 * tonyb clones kolla-ansible
10:42:23 <tonyb> coolsvap: Thanks
10:42:28 <coolsvap> we can take that on channel
10:42:30 <coolsvap> :)
10:42:37 <coolsvap> nothing from my side really
10:43:19 <tonyb> Anything else?
10:44:43 <dirk> tonyb: https://review.openstack.org/#/c/361517/
10:44:48 <dirk> can we remove the -2 there?
10:45:14 <coolsvap> dirk: I think no
10:45:43 <tonyb> dirk: We can remove the -2 but we shouldn't merge it until we've tested it
10:46:02 <dirk> yeah, we need a transition plan I guess
10:46:20 <tonyb> dirk: Also towards the end of the cycle it'll have no impact as we wont have bots generating chnages from that data
10:46:41 <tonyb> dirk: If you have time, the testing is
10:46:55 <tonyb> clone all the repos in projects.txt
10:47:16 <tonyb> run the bot to ensure they're current
10:47:20 <tonyb> appliy that review
10:47:26 <tonyb> re-run the bot
10:47:56 <tonyb> compare the diff if there are any then the change isn't accepable IMO
10:48:07 <dirk> thx for the explanation
10:48:11 <dirk> I probably will not be able to get to that
10:48:24 <dirk> not within the next 2 weeks at least
10:48:26 <tonyb> dirk: Yeah it's low priority
10:48:40 <tonyb> anyone else care to do that thing?
10:49:07 <tonyb> s/care/have time/
10:49:38 * coolsvap will be busy with kolla repo split next 2-4 weeks
10:49:50 <tonyb> coolsvap: Yeah that makes sense
10:51:09 <tonyb> Anything else?
10:51:11 <dirk> one more topic..
10:51:28 <dirk> we have this job gate-requirements-integration-dsvm-resolver-ubuntu-xenial that is non-voting and always failing
10:51:33 <dirk> any idea what it is about and what we should do about it?
10:51:45 <tonyb> dirk: Sure
10:52:34 <tonyb> dirk: you may or may not know that pip doesn't have a real depenacy resolver, lifeless was working on a branch of pip that added that feature
10:52:57 <tonyb> that job runs against that unmerged and probably defunct branch
10:53:35 <tonyb> dirk: If you upload a review to remove it we can get lifless to weigh in
10:53:46 <tonyb> dirk: I expcet he'd be find with it going
10:53:59 <tonyb> dirk: does that help?
10:54:06 <dirk> yep, thanks for the background
10:54:17 <tonyb> Cool
10:55:10 <tonyb> Are we done?
10:56:18 * tonyb hands out early marks (http://ozwords.org/?p=2742)
10:56:24 <tonyb> #endmeeting