10:00:01 <tonyb> #startmeeting requirements
10:00:02 <openstack> Meeting started Wed Nov 23 10:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
10:00:05 <openstack> The meeting name has been set to 'requirements'
10:00:14 <tonyb> #topic rollcall
10:00:24 <tonyb> sigmavirus, prometheanfire, number80, dirk, coolsvap, toabctl
10:00:33 <tonyb> Who's here?
10:00:38 <dirk> o/
10:00:46 <prometheanfire> o/
10:00:56 <toabctl> o/
10:01:35 <tonyb> okay that's cool.  I haven't seen coolsvap today so I assume he's AFK
10:01:45 <tonyb> #topic Any controversies in the Queue?
10:02:03 <tonyb> #link https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master
10:02:10 <tonyb> anything?
10:02:20 <prometheanfire> don't think so
10:02:50 <tonyb> https://review.openstack.org/382497 is slightly messy but nothing terrible
10:03:05 <tonyb> dirk: good catch there I messed up on that one
10:03:21 * tonyb +W'd the gunicorn addition tonight
10:03:46 <tonyb> I'll wrangle up a block comment to pair with it tomorrow
10:03:57 <dirk> only uncertainity is the heatclient thing for me
10:04:02 <prometheanfire> ya, that was an odd one
10:04:14 <dirk> it seems there was a regression with rally / neutron and heatclient 1.6.0
10:04:21 <dirk> it is unclear to me if that is addressed in 1.6.1 or not
10:04:35 <tonyb> dirk: Yeah 1.6.1 was expressly a regression fix
10:04:36 <dirk> also I couldn't figure out how to add a cross-*check to our upper-constraints update that would cover this going forward
10:05:00 <tonyb> dirk: what I'm worried about is the obvious issue masked a latent one that we'll now uncover
10:05:01 <dirk> I would like to either cover rally or neutron in the upper-constraints cross* checks, but it seems we only support running unit tests
10:05:05 <dirk> and unit tests did not uncover the issue
10:05:20 <tonyb> dirk: hence my "please wait on +Wing this for a day" request
10:06:05 <dirk> tonyb: sure
10:06:05 <tonyb> dirk: Yeah.  We can look at expanding the cross-gating but we'll never get to 100% coverage
10:06:42 <dirk> of course, but breaking neutron gating should be in the 80% of coverage that we can achieve
10:06:58 <dirk> apparently rally is part of neutron gating if I understood it correctly
10:08:20 <tonyb> dirk: if you have time to dig into it we can then do a cost/benefit analysis on expanding the gating there
10:08:42 <tonyb> dirk: but we've got a few other gating changes to do as a priority
10:08:59 <tonyb> dirk: py3.X, cross-gating on mitaka
10:09:03 <tonyb> etc
10:10:58 <tonyb> Does anyone have time to work with oslo to get https://review.openstack.org/#/c/388365/ merged or abandoned
10:11:31 <prometheanfire> I'm gonna guess it's someone overtesting
10:11:33 <dirk> tonyb: iirc there was a bugreport against glance for that
10:13:08 <tonyb> dirk: okay I can't see it but there are 376 open bugs to look through
10:13:38 <dirk> tonyb: I had it somewhere let me chase it
10:13:44 <prometheanfire> a note in the review would be nice
10:14:21 <tonyb> #action dirk To chase https://review.openstack.org/#/c/388365/  with oslo and glance teams
10:15:10 <tonyb> Anythign else? Moving on?
10:15:38 <prometheanfire> non
10:16:33 <tonyb> #topic Requirements priorities for Ocata
10:16:40 <tonyb> #link https://etherpad.openstack.org/p/requirements-track-constraints-usage
10:17:10 <tonyb> So as we discussed last week we need to get out constratints coverage up
10:17:28 <tonyb> we're currently just over 50% of projects in projects.txt with support
10:17:40 <tonyb> I updated the oslo.messaging change
10:17:54 <tonyb> #link https://review.openstack.org/#/c/394721/
10:18:10 <tonyb> once that merges we need to work on the rest of the list in the etherpad
10:18:58 <prometheanfire> neat
10:18:58 <tonyb> so over the next week can everyone have a think about how much time they can give to that and which projects they think they can work with/on?
10:19:23 * tonyb waits for jenkins votes .....
10:20:13 <dirk> tonyb: is this tools/tox_install.sh script synced by the proposal bot from the requirements repo at this point in time?
10:20:27 <tonyb> dirk no it isn't
10:20:46 <dirk> tonyb: sure, I can spend a bit of time on this.. could you sort out the "OK" lines or order the etherpad by the uc state instead of alphabetical?
10:20:46 <tonyb> dirk: we'll have to do that syncing manually / outside the proposal bot
10:20:54 <prometheanfire> can it be?
10:21:48 <prometheanfire> if so it'd decentralize the work
10:23:11 <tonyb> prometheanfire: Perhaps .... in BCN we decided that it was better to keep it out of infra but I rthink that was because we would fix tox to make the underlying problems go away
10:23:36 <prometheanfire> k
10:24:41 <tonyb> dirk: sure I'll just remove the OK lines
10:24:41 <prometheanfire> I'm gonna be busier in the coming month as I work on some internal gentoo things, so don't think I'll be of too much help other than reviewing, I may be able to pick off a couple of those though
10:24:55 <tonyb> prometheanfire: okay
10:26:19 <tonyb> #topic  Tasks from Etherpad
10:26:27 <tonyb> #link https://etherpad.openstack.org/p/requirements-tasks
10:26:56 <tonyb> I think we've stopped looking at that list often and we have a few priority items for this cycle
10:27:01 <tonyb> (which are on that list)
10:27:20 <tonyb> so I'm thinking we shoudl remove this as a std. item for the meeting
10:27:21 <prometheanfire> indeed
10:27:23 <tonyb> thoughts?
10:27:25 * dirk got distracted and dropps off the meeting
10:27:38 <prometheanfire> the list should be converted to bugs
10:28:10 <prometheanfire> and bugs targeted to the cycle (triaged)
10:29:08 <tonyb> prometheanfire: that could work.
10:30:23 <tonyb> prometheanfire: I guess it's only 20ish items perhaps a script would help there ...
10:30:23 <prometheanfire> item 3/4 is reoccuring at a very very quick glance
10:31:12 <tonyb> prometheanfire: Yeah.
10:31:28 <prometheanfire> we need to have that type of thing be autorenewing (calendar, not task list)
10:32:09 <prometheanfire> don't think there's a good way that's usable by everyone, iirc openstack has no central calendar
10:32:50 <tonyb> prometheanfire: right.  It'd have to be somethign we frobbed/created if we really wanted to do that thing
10:33:12 <tonyb> prometheanfire: but I don't know that recurring tasks like that woudl work well in LP/Storyboard
10:33:14 <prometheanfire> we, and probably others could be well served by it
10:33:22 <tonyb> prometheanfire: but we could ask the storybard team ....
10:34:01 <prometheanfire> ya, but back to the original issue first, do we agree on converting the tasks to bugs?
10:34:16 <tonyb> prometheanfire: write up your ideas and drop it on os-dev, I'm not convinced that a global calendar would work well but I may have the wrong idea
10:34:50 <prometheanfire> k
10:34:56 <tonyb> prometheanfire: perhaps we try the ones tagged as priority or goal for the next month and see how that works?
10:35:24 <prometheanfire> wfm
10:35:36 <tonyb> prometheanfire: okay.
10:36:10 <tonyb> #action prometheanfire to take the items in requirements-tasks tagged as an ocata goal/priority and convert to LP bugs
10:37:21 <tonyb> #topic Open Discussion
10:37:26 <prometheanfire> yep, that's scheduled for monday for me
10:37:38 <tonyb> I had a couple of things
10:38:29 <tonyb> Should we go through the open changes that are not -W and abandon them if they're "old" where old would be open to discussion ...
10:39:00 <tonyb> on one hand leaving them there doesn't really hurt ... but they're not really getting attention
10:39:37 <prometheanfire> email sent to os-dev
10:39:57 <prometheanfire> leave a comment and after a couple of days abandon
10:40:10 <prometheanfire> they may be useful for tracking tasks though
10:40:23 <prometheanfire> if they are attached to a task they should be -W
10:40:33 <prometheanfire> tonyb: this is a ptl level decision :P
10:40:47 <tonyb> prometheanfire: lol
10:40:58 <tonyb> prometheanfire: decisions aren't taken in a vaccum ;P
10:41:18 <prometheanfire> aint that the truth
10:41:43 <prometheanfire> learning all about politics in my new position within gentoo :P
10:41:51 <tonyb> :)
10:42:25 <prometheanfire> I'm in favor of abandoning things, but leave a warning, mention in that warning that -W for in progress things is fine
10:42:30 <prometheanfire> at least for now
10:42:43 <prometheanfire> if something sits -W for a year abandon :P
10:42:47 <prometheanfire> that's my opinion
10:43:20 <tonyb> prometheanfire: Thanks, I'll take a bash (no pun intended) at scripting that
10:44:00 <tonyb> the otehr thing came up with the 4.0.0.0b1 release of mistral ... shoudl we have prereleases in u-c?
10:44:18 <prometheanfire> I'm fine with it
10:44:25 <prometheanfire> a release is a release
10:44:33 <tonyb> I'm on the fence ... it's kida strange but it does mean that we can test stuff in smaller hunks
10:44:53 <tonyb> well pre-release isn't really a release
10:45:06 <prometheanfire> sha :P
10:45:18 <prometheanfire> we should just refrence by sha
10:45:45 <tonyb> hehe
10:46:24 <prometheanfire> I'm fine with any resoultion of the bump (fine or course grained)
10:46:30 <tonyb> anyone else with an open discussion topic?
10:46:39 <prometheanfire> ya
10:47:07 <prometheanfire> divergant lower constraints?  what's the story
10:48:00 <tonyb> prometheanfire: okay ... we talked about that last week but I still don't have it written up
10:48:31 <prometheanfire> this cycle is short and I'm not sure if we can make it is the main reason I ask now
10:48:53 <tonyb> prometheanfire: we're basically going with dhellman's plan to per-project management of the lower-bounds for things in *requirements.txt
10:49:15 <tonyb> prometheanfire: global-requirements will just become a list of thins that are approved and banned version of such
10:49:24 <prometheanfire> right
10:49:51 <prometheanfire> do we have a pilot project?
10:50:04 <tonyb> prometheanfire: Yeah it's going to be hard esp. given the prereq is "everyone uses constratins" which as we worked out we're at just over 50%
10:50:23 <prometheanfire> ya...
10:50:26 <tonyb> prometheanfire: we can't roll out the divergent part until we have the constratints part
10:50:52 <tonyb> then we can come up with a pilot project (probably swift)
10:51:04 <tonyb> then maybe Telemetry
10:51:11 <prometheanfire> is that a hard req? all projects need to use constraints before one can be divergant?
10:51:17 <prometheanfire> ya, swift is good
10:51:33 <tonyb> prometheanfire: it's a bit grey
10:51:50 <prometheanfire> just better safe than sorry I suppose
10:51:57 <tonyb> we need the constraints stuff to ensure the co-installability
10:52:00 <prometheanfire> that was all I had
10:52:05 <prometheanfire> right
10:52:13 <tonyb> as once we disable the sync jobs that's the only tool we have to make that assertion
10:52:41 <tonyb> so we think abotu it at say 85% depending on which projects are in that 85% ;P
10:52:49 <prometheanfire> :D
10:53:12 <tonyb> prometheanfire: for example right now swift doesn't use constratints so that's pretty much a deal breaker
10:54:12 <tonyb> okay ... so done?
10:54:18 <prometheanfire> done
10:55:04 <tonyb> #endmeeting