14:00:21 <johnthetubaguy> #startmeeting Nova
14:00:23 <openstack> Meeting started Thu Nov 12 14:00:21 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:27 <openstack> The meeting name has been set to 'nova'
14:00:34 <raildo> \o
14:00:35 <dims> o/
14:00:38 <jichen> o/
14:00:39 <edleafe> o/
14:00:39 <bauzas> \o
14:00:42 <PaulMurray> o/
14:00:43 <markus_z> o/
14:00:43 <scottda> hi
14:00:44 <alex_xu> o/
14:00:50 <mleroy> o/
14:00:51 <gcb_> o/
14:00:58 <johnthetubaguy> lets see who survived daylight savings / users a calendar
14:00:58 <andrearosa> hello
14:01:03 <alaski> o/
14:01:07 <sdague> o/
14:01:18 <johnthetubaguy> #topic Release Status
14:01:33 <johnthetubaguy> so this is mostly a duplicate from the last meeting, but...
14:01:43 <gibi> o/
14:01:48 <johnthetubaguy> #info November 19: Spec Review Day
14:01:59 <johnthetubaguy> #info December 3rd is also non-priority spec and blueprints freeze
14:02:00 <dguitarbite> o/
14:02:03 <sc68cal> o/
14:02:11 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Nova/Mitaka_Release_Schedule
14:02:18 <johnthetubaguy> here is an advert from the API subteam
14:02:29 <johnthetubaguy> #info Virtual doc sprint December 8th and 9th
14:02:36 <johnthetubaguy> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079220.html
14:02:44 <alex_xu> johnthetubaguy: thanks
14:02:56 <alexschm> o/
14:03:01 <johnthetubaguy> alex_xu: no problem, its super important we fix those things
14:03:09 <johnthetubaguy> so a quick check on blueprints
14:03:13 <alex_xu> johnthetubaguy: yea
14:03:48 <bauzas> alex_xu: so I need more understanding, is the docsprint planned to improve http://developer.openstack.org/api-ref-compute-v2.1.html ?
14:03:53 <johnthetubaguy> #info 77 blueprints approved for mitaka now, still have 104 specs in review, got 60 ish completed last release
14:04:08 <johnthetubaguy> bauzas: several things, thats included
14:04:13 <alex_xu> bauzas: yes
14:04:19 <johnthetubaguy> bauzas: I want to see the API concept guide make progress too
14:04:31 <bauzas> johnthetubaguy: okay, I guess the etherpad is the source of knowledge gotcha
14:04:32 * mriedem joins late
14:04:44 <johnthetubaguy> the swagger thing, I feel, is possible out of scope there, but anyways
14:04:55 <johnthetubaguy> yeah, that etherpad is good
14:05:08 <bauzas> ack
14:05:20 <johnthetubaguy> cool, so just wanted to talk about reno
14:05:25 <johnthetubaguy> bauzas: hows that going
14:05:40 <bauzas> so the reno changes are aligned for review
14:05:55 <bauzas> http://developer.openstack.org/api-ref-compute-v2.1.html
14:06:00 <mriedem> there will be a separate job for the reno docs right?
14:06:03 <bauzas> there are 2 changes per branch (master, liberty)
14:06:30 <bauzas> mriedem: yup, a project-config one https://review.openstack.org/#/c/242027/
14:06:49 <bauzas> so, like I said, reno is intended for liberty and master
14:07:03 <johnthetubaguy> its generating the release notes right?
14:07:07 <bauzas> yup
14:07:21 <bauzas> https://review.openstack.org/242007 is the foundational change
14:07:23 <johnthetubaguy> cools, just context for folks there
14:07:34 <bauzas> which deploys reno and setups a way to add relnotes
14:07:51 <bauzas> that one is sharing its changeid with the liberty backport
14:08:00 <johnthetubaguy> so we have the odd blueprint complete, so we might need to add something in there after the fact, but we can deal with that later
14:08:08 <bauzas> and then, I provided a relnote example for both branches
14:08:14 <bauzas> like https://review.openstack.org/242007
14:08:15 <claudiub> o/
14:08:17 <mriedem> so we have to move the liberty release notes in tree?
14:08:26 <bauzas> mriedem: zactly
14:08:30 <mriedem> harumph
14:08:31 <mriedem> ok
14:08:34 <bauzas> http://docs.openstack.org/developer/reno/usage.html#creating-new-release-notes
14:08:57 <bauzas> that's what I like with the new process actually
14:09:09 <mriedem> oh i suppose b/c with stable/liberty we do our own point releases now too
14:09:15 <bauzas> because it means our UpgradeImpact tag becomes less pedantic
14:09:17 <johnthetubaguy> yeah
14:09:36 <bauzas> mriedem: right, it's decoupled
14:09:48 <johnthetubaguy> so that brings us to the release CPL
14:10:20 <bauzas> johnthetubaguy: like I said in the previous meeting, I can help on that
14:10:41 <johnthetubaguy> bauzas: that help would be very welcome
14:10:46 <bauzas> but I welcome any help too :)
14:10:51 <bauzas> heh
14:11:02 <johnthetubaguy> mriedem: you are doing good stuff with stable and python-novaclient already, I think it makes sense you keep doing that
14:11:11 <sdague> so I'm assuming we're going to reno every API change
14:11:11 <mriedem> alright
14:11:22 <bauzas> sdague: that makes sense to me
14:11:25 <mriedem> i had to think awhile to remember what CPL is
14:11:49 <johnthetubaguy> ah, yeah, CPL = cross project liaison
14:12:03 <bauzas> sdague: there are some predefined sections for every relnote, but we could certainly ask for an API one http://docs.openstack.org/developer/reno/usage.html#editing-a-release-note
14:12:14 <johnthetubaguy> so mriedem, bauzas lets work out how to make sure the right things happen with release stuff
14:12:40 <bauzas> agreed
14:12:50 <mriedem> ack
14:12:55 <johnthetubaguy> so python-novaclient, its probably time we cut a release soon?
14:13:12 <johnthetubaguy> we were going to try and release a bit like oslo, i.e. more frequently
14:13:16 <mriedem> sdague said mordred had changes to make
14:13:21 <sdague> one thing about that, I blocked the v1.1 remove
14:13:37 <johnthetubaguy> sdague: because too many folks are using it?
14:13:38 <sdague> because mordred was poking at something else that was going to require a major bump
14:13:45 <sdague> no, I think we should remove it
14:13:49 <mordred> I didn't do it
14:13:52 <mordred> wait
14:13:59 <johnthetubaguy> oh, I see just delaying for the major bump
14:14:02 <mriedem> we're just lining up tihngs that cause a 3.0 version
14:14:06 <johnthetubaguy> yeah, makes sense
14:14:09 <mordred> oh - yeah. I'd love to get in on that
14:14:19 <johnthetubaguy> sounds like a plan
14:14:28 <sdague> yeh, we should probably figure out a good way to stack up the stuff we want in that would require a major bump
14:14:29 <johnthetubaguy> what the chances of us lining that all up by Tuesday?
14:14:38 <johnthetubaguy> zero ish?
14:14:41 <mordred> I can get my changes up by then
14:14:42 <sdague> johnthetubaguy: we can cut a release without that one change
14:15:00 <sdague> I just think we should actually be a little more coordinated on the v3 requiring changes
14:15:03 <johnthetubaguy> sdague: thats a not a bad idea, get a minor out, while we line up the other stuff
14:15:17 <mriedem> we need to get better about signaling to the core team when we're going to do a release though, so we don't approve things that we don't want in
14:15:20 * johnthetubaguy wonders about a feature branch for v3, maybe that over kill?
14:15:34 <johnthetubaguy> mriedem: very true
14:15:36 <sdague> johnthetubaguy: honestly, I was thinking a similar thing
14:15:36 <mriedem> summit week was a bit chaotic with novaclient reverts and releases
14:15:41 <sdague> yeh, it was
14:16:08 <johnthetubaguy> we need to fix that test coverage at some point too
14:16:20 <johnthetubaguy> but lets focus on the release thing
14:16:22 <mordred> so - question about how much we can break in v3
14:16:33 <mordred> oh, wait. nm.
14:16:46 <mordred> sdague and I already talked about that - I'm still waking up
14:16:53 <mriedem> v3 as in keystone v3?
14:16:53 <johnthetubaguy> heh, no worries
14:17:00 <sdague> mriedem: as in novaclient v3
14:17:04 <johnthetubaguy> yeah, that
14:17:08 <mriedem> ok
14:17:13 <sdague> I think it was mostly the NOVA_ env variables for config
14:17:22 <sdague> being no longer supported
14:17:30 <mordred> yah. I'd love to make them die because it makes things eaiser on the occ/ksa front
14:17:31 <johnthetubaguy> oh right, good points
14:17:37 <mordred> but - if we need to keep them, I can keep them
14:17:56 <sdague> so, anyway, we should huddle up about the non backwards compat changes we want this cycle
14:18:15 <johnthetubaguy> yeah, leaving that with sdague and mriedem to report back to the ML with a plan?
14:18:25 <bauzas> oh, if there is a v3 window, maybe that's a good opportunity for seeing what we want to stop supporting - like some contrib shell scripts that I'm questioning :)
14:18:45 <johnthetubaguy> in the mean time we do a minor version release anyways?
14:18:48 <bauzas> so, +1 for a feature branch :)
14:18:54 <sdague> yes, lets do a minor version release
14:19:17 <mriedem> #action mriedem to request a novaclient minor version release for mitaka
14:19:18 <sdague> I think the project id optional thing is not yet released yet, and we'll need that for project id optional in nova
14:19:23 <johnthetubaguy> mriedem: do we want to send an ML note about about a proposed release, just so we know whats happening, thinking thats nice and light weight?
14:19:34 <mriedem> sure
14:19:43 <johnthetubaguy> lets try that for size
14:19:46 <johnthetubaguy> cools
14:20:03 <johnthetubaguy> so I guess one thing I forgot to mention at the summit
14:20:18 <johnthetubaguy> we are still planning to do "milestone" releases for Mitaka
14:20:55 <johnthetubaguy> we get to choose when now, but I am just going to aim for the usual tuesday releases, split to thursday if we must
14:21:25 <bauzas> wfm
14:21:30 <johnthetubaguy> the question is do we want to move to ironic's way of doing actual semver for the milestones, rather than a beta release stuff
14:22:01 <mriedem> so 13.1.0?
14:22:09 <johnthetubaguy> yeah, vs 13.0.0.a1
14:22:18 <bauzas> 13.0.0a1 rather
14:22:18 <johnthetubaguy> well I guess 13.0.0 first
14:22:21 <bauzas> ah snap
14:22:29 <johnthetubaguy> bauzas: yeah, thats it
14:22:34 <mriedem> i guess i assumed 13.1.0 would be first stable/mitaka release
14:22:40 <mriedem> but that's just b/c that's how it's always been
14:22:45 <bauzas> 13.1 being the stable point release AFAIU
14:22:46 <sdague> honestly, let's just stick with the old way until there is a reason to change
14:22:58 <bauzas> sdague: +1
14:23:07 <johnthetubaguy> sdague: so thats my take, I just wanted to make sure we didn't do that by acciedent
14:23:08 <bauzas> in particular given the many release changes for this cycle :)
14:23:24 <sdague> yeh, if it ain't broke...
14:23:27 <edleafe> the difference being one signifies beta, and the other stable?
14:23:40 <johnthetubaguy> well we allow people to deploy of master
14:23:47 <johnthetubaguy> so the milestones mean more than you think
14:23:51 <bauzas> right
14:23:56 <bauzas> it's a pinned release
14:24:08 <johnthetubaguy> but honestly, we should move on really
14:24:38 <johnthetubaguy> #topic Regular Reminders
14:24:46 <johnthetubaguy> so we have reviews highlighted by subteams
14:24:52 <johnthetubaguy> there are some changes in there now
14:24:59 <johnthetubaguy> #link https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
14:25:08 <johnthetubaguy> priority specs are listed in here:
14:25:18 <johnthetubaguy> #link https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
14:25:33 <johnthetubaguy> #topic Bugs
14:25:36 <sdague> so, why did we do this as 2 etherpads this time?
14:25:54 <sdague> that caused some confusion yesterday
14:26:05 <dansmith> yeah
14:26:12 <johnthetubaguy> so the old one didn't change, its all code
14:26:16 <mriedem> the first etherpad is the same as last release
14:26:24 <mriedem> the latter is to categorize specs for review
14:26:33 <mriedem> there is some overlap
14:26:33 <sdague> I though the old one had specs in it as well
14:26:40 <johnthetubaguy> we could just mush them together if its easier, it just seemed like it work worth separating
14:26:41 <mriedem> should just be code
14:26:46 <dansmith> we put specs on the old one early on didn't we?
14:26:53 <johnthetubaguy> hmm, maybe we did
14:27:06 <dansmith> anyway, it's just confusing to me,
14:27:11 <dansmith> because they look similar,
14:27:18 <dansmith> and you can't tell a thing is a spec by the review url
14:27:32 <dansmith> so I dunno, seems like one place would be fine
14:27:33 <johnthetubaguy> so I could cut and past the specs into the code one?
14:27:42 <johnthetubaguy> simpler is better
14:27:52 <raildo> johnthetubaguy: can anyone suggest a feature for this nova priorities etherpad?
14:28:04 <mriedem> i'd actually prefer separataion
14:28:07 <johnthetubaguy> raildo: anyone can create a subteam
14:28:12 <mriedem> there are a lot of specs
14:28:28 <johnthetubaguy> so the good news is the spec one dies on December 3rd
14:28:31 <dansmith> is the goal of the second one to list every spec?
14:28:36 <mriedem> kill! kill!
14:28:38 <raildo> johnthetubaguy: nice
14:29:25 <johnthetubaguy> so I think its worth trying the separation, if its a flop lets remember not to do that next time?
14:29:29 <sdague> ok
14:29:44 <johnthetubaguy> so turns out we are in the bugs topic, oops
14:29:51 <johnthetubaguy> markus_z: whats up?
14:29:55 <bauzas> undo :)
14:30:15 <markus_z> I started the bug shaming thing on the ML
14:30:18 <markus_z> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/078713.html
14:30:26 <markus_z> Would be cool to get feedback
14:30:43 <markus_z> #info Top 3 subteams with most "New" bugs: untagged: 25, libvirt: 14, volumes: 11
14:30:46 <johnthetubaguy> I think there was a call to add low-hanging-fruit into the tracking
14:30:57 <johnthetubaguy> but I like the tracking
14:31:13 <johnthetubaguy> we know where we are at
14:31:14 <markus_z> It was a call out to tag more bugs with low-hanging-fruit
14:31:26 <johnthetubaguy> yeah, just curious about the count
14:31:47 <markus_z> I will add it in the next mail
14:31:48 <bauzas> in general those unassigned are taking in the next following minutes
14:31:54 <bauzas> I'm not that worried
14:31:58 <johnthetubaguy> although clearly one million stats and it looks silly
14:32:24 <johnthetubaguy> mriedem: how is stable doing, is it time to release any of the branches?
14:32:30 <bauzas> the thing is, we should rather see how many assigned low-hanging-fruits are actually in progress and possibly unassign
14:32:31 <mriedem> stable/juno freeze is today
14:32:42 <mriedem> 2014.2.4 is planned for next thursday
14:32:58 <johnthetubaguy> #info Thursday Nov 12 stable/juno freeze
14:32:59 <mriedem> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/juno,n,z
14:32:59 <johnthetubaguy> #info Thursday Nov 19 release 2014.2.4
14:33:15 <sdague> will be happy to eol juno
14:33:19 <mriedem> there are a couple of changes
14:33:25 <markus_z> bauzas: that's the normal step when looking for stale bugs, right?
14:33:34 <mriedem> i think i'm going to recheck babysit the one that's approved and let the rest die on the vine
14:33:41 <bauzas> markus_z: most newcomers don't do that
14:33:47 <johnthetubaguy> so the freeze, remind me, does that mean no more merges after today, or no more proposals?
14:33:52 <bauzas> markus_z: but let's bring the convo out of here
14:34:07 <mriedem> it also appears that gate-grenade-dsvm-ironic-sideways is borked on stable/juno
14:34:09 <mriedem> blocking lots of things
14:34:15 <mriedem> trying to get ironic people to look but haven't heard much
14:34:17 <mriedem> jroll: ^
14:34:31 <sdague> mriedem: honestly, we should just delete that job
14:34:45 <mriedem> does it actually try an upgrade?
14:34:52 <sdague> that was about ensuring there was a baremetal -> ironic transition on juno
14:35:00 <mriedem> oh
14:35:01 <dansmith> sideways means bm to ironic yes?
14:35:02 <johnthetubaguy> oh...
14:35:05 <sdague> but if people are waiting until now to do that juno transition
14:35:11 <sdague> well, they are kindof f'ed
14:35:16 <mriedem> heh, yeah, i'll drop it
14:35:16 <sdague> as we're about to eol it all
14:36:02 <johnthetubaguy> cool, so I guess we need to unblock that, and get the stuff merged, right?
14:36:10 <johnthetubaguy> well, fixed up and merged
14:36:15 <mriedem> yeah, i'll take those todos
14:36:21 <johnthetubaguy> sweet, thank you
14:36:34 <sdague> out of curiosity, does ironic still support juno at all themselves?
14:36:40 <johnthetubaguy> action mriedem to give stable/juno much love
14:36:48 <johnthetubaguy> oops
14:36:50 <johnthetubaguy> #action mriedem to give stable/juno much love
14:36:52 <devananda> ++ to dropping the juno sideways job
14:36:56 <johnthetubaguy> OK...
14:36:58 <mriedem> sdague: not really https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:stable/juno,n,z
14:37:20 <johnthetubaguy> #topic Open discussion
14:37:21 <sdague> so maybe ironic should actually have eoled their branch :)
14:37:46 <johnthetubaguy> so... I missed at bit earleir
14:37:49 <johnthetubaguy> specless blueprints
14:37:59 <alexschm> I'd like to ask for reviews on the following bugfix: https://review.openstack.org/#/c/215102/
14:38:07 <johnthetubaguy> #link https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
14:38:14 <johnthetubaguy> there are loads of blueprints in there
14:38:23 <johnthetubaguy> I have added comments on them about what I think we should do
14:38:25 <alexschm> It's a libvirt driver change and got a +2 from danpb already two months ago
14:38:44 <johnthetubaguy> if there are any objections, do let me know ASAP, and I will get them merged / dropped off the specless list as required
14:39:18 <johnthetubaguy> I don't remember any controversial ones, that I didn't just reject to be reviewed as a spec
14:39:35 <johnthetubaguy> Ok, any more for any more?
14:39:36 <PaulMurray> johnthetubaguy, Quick note on the mid cycle
14:39:48 <johnthetubaguy> PaulMurray: fire away
14:39:58 <PaulMurray> I will send out an email in the next couple of days with details about block bookings
14:40:04 <PaulMurray> and web site for all details
14:40:14 <johnthetubaguy> PaulMurray: is it a cheap-ish hotel?
14:40:30 <PaulMurray> its cheeper than listed
14:40:32 <bauzas> how many people registered so far ?
14:40:47 <johnthetubaguy> PaulMurray: well thats an important bit, true
14:40:47 <sdague> https://review.openstack.org/#/q/topic:grenade_multinode,n,z - grenade multinode changes to make that voting, and drop partial-ncpu from master
14:40:49 <PaulMurray> don't know - mikal set up the eventbrite ticket
14:40:59 <bauzas> ack
14:41:11 <PaulMurray> our site will be seperate from eventbrite
14:41:25 <johnthetubaguy> I have not heard from mikal on numbers either, worth asking him
14:41:27 <PaulMurray> unfortunately - but will try to reconcile to avoid mistakes
14:41:35 <PaulMurray> will do
14:41:38 <johnthetubaguy> PaulMurray: I am sure mikal can update that all for you
14:41:39 <sdague> yeh, need that list from mikal as well, because I think a few of us were thinking about going to the dr who experience on friday post event (given that it's close)
14:42:01 <sdague> and seemed better to just coord with people that signed up, vs. whole world
14:42:02 <bauzas> doctor who experience ? woah
14:42:06 <PaulMurray> you know - your not the only one to mention that
14:42:14 <sdague> yeh, it came up at summit
14:42:16 <PaulMurray> shoud we organise a trip? :)
14:42:22 <sdague> PaulMurray: yes
14:42:32 <johnthetubaguy> ah, thats work looking at
14:42:50 <bauzas> yeah, most of us are holding to book our flights until the details are sorted out
14:43:09 <johnthetubaguy> sdague: the grenade job, do we do the scheme changes with the code running yet?
14:43:10 <PaulMurray> bauzas, for the dr who experience or for the mid cycle?
14:43:16 <markus_z> I still have to go to the company internal approval process, that's why I didn't yet enrolled for the midcycle
14:43:22 <dansmith> PaulMurray: for your details
14:43:25 <markus_z> Would be cool to get the information too
14:43:25 <sdague> johnthetubaguy: can you rephrase the question?
14:43:38 <bauzas> PaulMurray: for the midcycle
14:43:45 <dansmith> johnthetubaguy: no, we don't
14:43:54 <dansmith> johnthetubaguy: I'd like to have a job to do that, but it's a bit wasteful
14:43:55 <johnthetubaguy> sdague: sorry, sure, I am thinking about online schema migrations, and how we check they are online, thats probably not the right approach
14:44:14 <mriedem> dansmith: experimental queue :)
14:44:15 <dansmith> johnthetubaguy: perhaps an experimental job to do that and we can run it periodically
14:44:21 <johnthetubaguy> dansmith: maybe we could do some DB functional tests against while running it, or something
14:44:29 <johnthetubaguy> mriedem: yeah, thats a good point
14:44:34 <dansmith> johnthetubaguy: we can't really
14:44:52 <sdague> dansmith: we can't with a conductor and an old schema?
14:44:55 <johnthetubaguy> dansmith: run stable/liberty tests or something
14:44:58 <dansmith> johnthetubaguy: I think an grenade job in experimental that just applies then and never upgrades anything is the way to go
14:45:04 <dansmith> sdague: opposite
14:45:16 <jroll> sdague: mriedem: do you still need something from me re: juno or did y'all figure it out
14:45:23 <mriedem> jroll: ignore
14:45:25 <mriedem> jroll: https://review.openstack.org/#/c/244688/
14:45:35 <sdague> dansmith: ok, let's ponder offline
14:45:43 <dansmith> yep
14:45:43 <jroll> mriedem: cool, thanks
14:45:44 <johnthetubaguy> dansmith: oh, gotcha, thats a good point, could we not just do the schema migrations first on all genade jobs
14:45:49 <johnthetubaguy> sdague: yeah, I got distracted
14:45:59 <johnthetubaguy> so...
14:46:06 <sdague> anyway, on the grenade multinode change it's mostly infra / test changes to get us going, however it would be good for people to review
14:46:12 <johnthetubaguy> I think we have wondered off into the weeds, so we are probably done now?
14:46:23 <mriedem> maybe one last thing
14:46:24 <sdague> the big last piece is a test to ensure we actually can run computes on all the nodes
14:46:31 <sdague> which is in that stack
14:46:42 <mriedem> https://review.openstack.org/#/c/244330/ - an experimental queue job for cells v1 + neutron
14:46:52 <sdague> to mitigate against the worker not being able to communicate with the controller post upgrade
14:46:56 <sdague> and us passing anyway
14:47:25 <sdague> cells v1 + neutron seems like an epic distraction from moving forward with cells v2
14:48:10 <sdague> I'm really afraid it means we lose another cycle or two getting to a model we want
14:48:32 <mriedem> i think that's a bit premature
14:48:58 <mriedem> it's not like this is a voting job that everyone sees daily now
14:49:08 <sdague> maybe, I know I've spent at least 4 hours in the last week having to care about cells because of this effort
14:49:09 <johnthetubaguy> so its tempting if we could turn off the nova-network job
14:49:19 <mriedem> sdague: that wasn't b/c of this
14:49:28 <mriedem> johnthetubaguy: no we aren't doing that
14:49:30 <dansmith> johnthetubaguy: we have to implement event callbacks for cells at a minimum for being able to gate on this
14:49:31 <sdague> mriedem: no, it was because of cells v1 in general
14:49:34 <mriedem> cells v1 doesn't have external events support
14:49:36 <johnthetubaguy> dansmith: true
14:49:44 <mriedem> dansmith: which there is a change up for
14:49:48 <mriedem> but still
14:49:51 <johnthetubaguy> yeah
14:49:53 <mriedem> we want a cells v1 job
14:49:58 <mriedem> we have nova-net, this isn't replacing that
14:50:03 <dansmith> if this is never going further than an experimental job then fine, whatever
14:50:08 <mriedem> bdm stuff blew up last week and is still being worked
14:50:25 <johnthetubaguy> thats the alternative, keep it experimental
14:50:33 <dansmith> mriedem: can you link me that change?
14:50:40 <mriedem> sec
14:50:52 <mriedem> https://review.openstack.org/#/c/184155/
14:50:53 <johnthetubaguy> having two cells v1 jobs all the time seems like the wrong call, somehow
14:50:54 <sdague> right, but the point is that every time we take our eye of the cells v2 stuff to duct tape back cells v1 which keeps slowing us down with blow ups like the bdm thing, we push cells v2 out further
14:51:02 <mriedem> johnthetubaguy: it wouldn't be all the time
14:51:09 <mriedem> nova-net is gating and voting
14:51:16 <mriedem> neutron is experimental queue (on demand)
14:51:18 <johnthetubaguy> mriedem: yeah, I think its fine in experimental
14:51:55 <johnthetubaguy> so I am working hard to get more effort behind cells v2, internally
14:52:05 <johnthetubaguy> in the hope to hurry that along more
14:52:13 <johnthetubaguy> its critical we get there ASAP
14:52:22 <dansmith> I was going to work on cellsv2 more this cycle
14:52:45 <dansmith> but I've spent a lot of time on cellsv1 bugs already, and plan to go review this cellsv1 event patch (which is wrong)
14:53:09 <sdague> right, that's the issue, this keeps being messaged as "it's not a big deal" and then it's death by a thousand paper cuts
14:53:20 <dansmith> right
14:53:39 <dansmith> also,
14:53:45 <johnthetubaguy> so should we deprecate it now? to make it clear upstream will not maintain that job next release
14:53:48 <dansmith> mriedem's single cell job will show that this event patch works
14:53:54 <dansmith> but it doesn't for multiple cells properly
14:53:54 <johnthetubaguy> its up to third party CI if we want it?
14:54:01 <sdague> I got dragged into cells stuff because I couldn't land devstack patches until it got reasonably passing again
14:55:30 <sdague> personally, I think the important thing is to make it clear that the focus is moving forward. A lot of things are broken by design in cells v1 (like the locked mechanism)
14:55:31 <mriedem> i wouldn't be on board with deprecating a cells job (the one we have voting today) until v2 is ready
14:55:48 <sdague> and cellsv1 will get no new features
14:55:51 <alaski> so I was originally of the opinion that landing some of the code that operators are holding would be a good thing, but I do agree that this is taking up valuable time from v2
14:56:10 <sdague> we have to be firm on the no new features front
14:56:15 <sdague> otherwise, we're never going to get to v2
14:56:39 <johnthetubaguy> so I am really starting to lean that way
14:56:44 <johnthetubaguy> the options are:
14:56:54 <dansmith> several of us have spent serious time on the exisiting bdm problem with v1 in the last week and a half
14:56:56 <alaski> so, only regressions then?  like the bdm failures
14:57:05 <johnthetubaguy> 1) drop cells v1 job, and be clear its dead
14:57:23 <johnthetubaguy> 2) add a few missing bits from cells v1
14:57:26 <mriedem> alaski: the bdm thing wasn't actually a regression, it was just a new test that exposed the problem
14:57:33 <alaski> I don't think we should drop the job.  I think we should decide do we fix failures or skip them
14:57:36 <johnthetubaguy> 3) feature freeze v1 hard, but keep on top of regressions
14:57:42 <bauzas> the bdm failure originally came from something which was skipped and then enabled
14:57:52 <dansmith> I think #3
14:57:56 <bauzas> without having properly been tested with cells
14:57:58 <sdague> definitely #3
14:57:59 <johnthetubaguy> right
14:58:05 <bauzas> #3 +1
14:58:07 <alaski> mriedem: okay, wasn't quite aware of that
14:58:09 <dansmith> regressions only, not even fixing things that are known broken
14:58:22 <sdague> and realize that because new tests are getting added, and cells is massively under tested, fixing in #3 might mean skipping a test
14:58:24 <bauzas> so the bdm stuff was even not a regression
14:58:28 <johnthetubaguy> I just want a way to message its expense with regressions only, that means feature freeze to make that possible
14:58:33 <sdague> yeh, like dansmith said, only fixing actual regressions
14:58:39 <sdague> not new bugs that were exposed
14:58:42 <bauzas> +1
14:58:45 <sdague> that were always there
14:59:04 <mriedem> we have 1 min
14:59:05 <johnthetubaguy> did we approve any cells features already?
14:59:08 <mriedem> no
14:59:11 <mriedem> they are all -2
14:59:25 <johnthetubaguy> OK, so they stay that way is the concenus
14:59:37 <alaski> works for me
14:59:40 <johnthetubaguy> I don't feel we have a choice, so I agree with that
14:59:59 <johnthetubaguy> OK, so thanks all
15:00:04 <johnthetubaguy> #endmeeting