14:01:46 <johnthetubaguy> #startmeeting nova
14:01:47 <openstack> Meeting started Thu Jun 25 14:01:46 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:48 <beagles> o/
14:01:50 <dansmith> o/
14:01:51 <openstack> The meeting name has been set to 'nova'
14:01:52 <thangp> o/
14:01:53 <melwitt> o/
14:01:54 <edleafe> o/
14:01:55 <mriedem> o/
14:01:59 <llu-laptop> o/
14:01:59 <neiljerram> o/
14:02:00 <rgerganov> o/
14:02:03 <markus_z> o/
14:02:04 <bauzas> \.............o............/
14:02:04 <artom> o~
14:02:07 <alaski> o/
14:02:07 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:02:14 <johnthetubaguy> #topic Release Status
14:02:24 <claudiub|2> o/
14:02:26 <johnthetubaguy> so liberty-1 is tagged and out there
14:02:34 <johnthetubaguy> today is spec freeze day
14:02:45 <johnthetubaguy> ... that means
14:02:49 <lpetrut1> o/
14:02:53 <scheuran> o/
14:03:06 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
14:03:09 <atuvenie_> o/
14:03:13 <bauzas> no longer pings about spec reviews ?
14:03:18 <bauzas> yay!
14:03:29 <johnthetubaguy> so the plan for liberty we agreed was...
14:03:40 <garyk> johnthetubaguy: will there be a spec freeze exception window?
14:04:15 <johnthetubaguy> #info at the summit we agreed backlog nova-specs allowed at all times during liberty
14:04:32 <johnthetubaguy> garyk: its should be documented in the above wiki page
14:04:40 <johnthetubaguy> as send out to the ML a few times
14:04:51 <johnthetubaguy> but the wiki page is not that clear, sadly
14:05:03 <mnestratov|2> o/
14:05:08 <sudipto> o/
14:05:08 <johnthetubaguy> so the basic idea is this, raise any exceptions in the meeting next wekk
14:05:18 <johnthetubaguy> instead of the specless blueprints, we talk exceptions
14:05:33 <mriedem> meeting or ML? or ML before meeting?
14:05:41 <mriedem> otherwise the meeting will be nothing but arguing over spec exceptions
14:05:46 <johnthetubaguy> mriedem: ideally in the meeting agenda, before the meeting
14:06:10 <johnthetubaguy> now, the theory is, folks will have already voted on the specs one way or the other
14:06:29 <johnthetubaguy> so it would just be a final agreement one way or the other
14:06:58 <johnthetubaguy> baring in mind, you can just move your spec to a backlog spec and get it merged that way, although the idea is that you are agreeing things for a future release in there
14:07:03 <johnthetubaguy> now priority specs
14:07:30 <johnthetubaguy> I am thinking we given them at least a week or two, nova-drivers feel free to keep merging those ones at will
14:07:41 <johnthetubaguy> ... so lets step back a bit
14:07:54 <ndipanov> ah-hah
14:08:00 <ndipanov> so priority stuff still can land
14:08:07 <ndipanov> ok
14:08:08 <johnthetubaguy> ndipanov: yep
14:08:16 <ndipanov> plug:
14:08:26 <ndipanov> bah copy paste fail
14:08:34 <ndipanov> nvm I'll chase ppl
14:08:57 <bauzas> assuming corresponding subteams would appreciate if a proposer could step up during their weekly meetings and discuss on the claim for a priority
14:09:02 <johnthetubaguy> so why have a freeze at all? the original idea is to move from the big spec reviews to doing coding and code reviews, to stop the distraction
14:09:25 <johnthetubaguy> now the idea of opening up the backlog specs is to try and soften that
14:09:48 <jaypipes> johnthetubaguy: that hasn't worked.
14:09:49 <johnthetubaguy> I also hope we move away from approving specs per release, to something thats slightly less brutal
14:10:03 <jaypipes> johnthetubaguy: why don't we just do that.
14:10:05 <melwitt> +1
14:10:07 <johnthetubaguy> jaypipes: we haven't tried backlog specs yet though, right?
14:10:13 <garyk> +1
14:10:19 <jaypipes> johnthetubaguy: it's just process for the sake of process, though.
14:10:21 <mriedem> we don't really have a 6 month release cycle anymore right?
14:10:27 <mriedem> now that every project has it's own versions
14:10:27 <edleafe> so putting a spec in backlog means agreeing that it won't be released until April 2016, right?
14:10:31 <mriedem> we just release when we want
14:10:33 <mriedem> using semver
14:10:42 <mnestratov> jaypipes: +1
14:10:45 <ndipanov> mriedem, really?
14:10:48 <mriedem> ndipanov: yes
14:10:51 <ndipanov> I mean in theory
14:10:54 <johnthetubaguy> mriedem: apart from we accidentally agreed to align with everyone this time
14:10:54 <ndipanov> but not Nova
14:10:58 <dansmith> so, I really don't think it's process for the sake of it
14:11:03 <mriedem> johnthetubaguy: oh
14:11:04 <edleafe> mriedem: are the translation teams on board with that?
14:11:08 <dansmith> because when people get a spec merged,
14:11:09 <ndipanov> dansmith, we know you don't and it;s ok
14:11:14 <mriedem> edleafe: ask ttx?
14:11:16 <jaypipes> dansmith: the backlog stuff, not specs in general.
14:11:22 <dansmith> ndipanov: cool, then I won't finish my thought, thanks a lot!
14:11:24 <johnthetubaguy> now we do need a review of a spec, here and there
14:11:26 <mriedem> edleafe: i think you get whatever trnaslations are done when you cut the release
14:11:28 <ndipanov> please do
14:11:29 <johnthetubaguy> as things change
14:11:37 <johnthetubaguy> which is why we do the per release thing
14:11:40 <jaypipes> dansmith: in other words, for *this* type of spec, put it here, and for *this* type of spec, put it in this directory, etc...
14:11:43 <johnthetubaguy> so we still need some way to revisit things
14:11:50 <jaypipes> johnthetubaguy: it's very Gorgon.
14:12:07 * mriedem googles gorgon
14:12:17 <edleafe> mriedem: hmmm... well, ttx was pretty strongly against that out-of-sync translation model last time I discussed it with him
14:12:26 <johnthetubaguy> so its the reason why, its not why we have to keep doing it that way, we can change for sure
14:12:41 <mriedem> edleafe: then we should have lock step releases on planned schedules i guess....
14:12:47 <mriedem> someone should make up their mind
14:13:00 <johnthetubaguy> mriedem: so our official plan on releases, I think, is see how ironic goes, and consider changing things next time
14:13:10 <edleafe> mriedem: heh, I tried to make that argument before
14:13:12 <jaypipes> sorry, I meant "Vogon"...
14:13:25 <beagles> ahhhhh
14:13:26 <edleafe> mriedem: got told it wasn't possible because "translations"
14:13:27 <bauzas> good bye and thanks for the fish
14:13:28 <jaypipes> https://en.wikipedia.org/wiki/Vogon
14:13:28 <garyk> mriedem: for the me the release process is unclear. say 30 out of 60 patche shave landed - do we release a version?
14:13:31 <johnthetubaguy> jaypipes: ahhh, now I get you
14:13:45 <mriedem> garyk: yeah idk how that works either
14:13:47 <johnthetubaguy> jaypipes: agreed, I was more meaning thats why we have it, for when we change things
14:14:02 <johnthetubaguy> now... we could keep this debate going, but I think we should move this to the end of the meeting
14:14:09 <ndipanov> right
14:14:11 <mriedem> garyk: i assume things would have to be completed in a milestone and we'd release on milestones with whatever is done
14:14:21 <garyk> ok
14:14:27 <johnthetubaguy> the idea right now is, keep the backlog directory open
14:14:31 <johnthetubaguy> we define what goes in there here:
14:14:48 <johnthetubaguy> http://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html
14:15:00 <johnthetubaguy> basically, any part of the spec is allowed to be skipped
14:15:08 <johnthetubaguy> appart from the problem spec
14:15:28 <johnthetubaguy> Now the BIG TODO is how do you get your spec out of the backlog, and where does it go
14:15:43 <mriedem> purgatory :)
14:15:44 <ndipanov> johnthetubaguy, well currently (and imho) wrongly ppl use specs as kind of a guarantee thet they can go and code it up
14:15:47 <johnthetubaguy> I am punting on that for now, and running liberty on the old system
14:16:02 <ndipanov> this gives them no such guarantees so I fear very few people will do it
14:16:20 <johnthetubaguy> ndipanov: this goes back to us needing to take a step back and properly document why we do what we do, and what it really means
14:16:23 <ndipanov> without the "how to get out" bit
14:16:53 <johnthetubaguy> my point really, is we need a plan to get out of the backlog
14:17:03 <johnthetubaguy> but I don't see us getting agreement on that before the midcycle
14:17:21 <johnthetubaguy> we can talk about proposals there, and follow up on the ML, etc
14:17:28 <ndipanov> also I fear it could turn into a graveyard of "I had an idea in the shower last night" specs
14:17:51 <johnthetubaguy> ndipanov: right, we need to define why you would want to bother with a spec backlog
14:17:59 <edleafe> ndipanov: so now we need a proper burial process? :)
14:18:25 <johnthetubaguy> anyways, do get in touch directly if you have idea and concerns
14:18:33 <ndipanov> 2x +2s by nova-wake-cores
14:18:40 <johnthetubaguy> I am trying to collect these and draw together a proposal for the midcylce
14:18:45 <mriedem> jogo always had the runways concept
14:18:59 <mriedem> but moving on
14:19:01 <johnthetubaguy> mriedem: yeah, I liked that a lot, I think sdague had a lot to do with that as well
14:19:07 <johnthetubaguy> yeah, lets move on from this
14:19:24 <ndipanov> it's needless paperwork with several more bottlenecks but otherwise cool
14:19:31 <johnthetubaguy> it sucks, but we have ideas to move forward from here
14:19:31 <ndipanov> aka not cool at all
14:19:34 <ndipanov> but let's move on
14:20:00 <johnthetubaguy> ndipanov: we have plans to remove them, and we have less that the last release, at least from where I am sat
14:20:09 <ndipanov> I was talking about runways
14:20:24 <ndipanov> :)
14:20:29 <ndipanov> now I mean
14:20:47 <mriedem> moving on
14:21:00 <ndipanov> yes please
14:21:02 <johnthetubaguy> so turns out we are really bad at commuicating and getting buy in for process ideas
14:21:06 <johnthetubaguy> I am attempting to fix that
14:21:11 <johnthetubaguy> please help with that
14:21:16 <johnthetubaguy> so the next topic...
14:21:24 <markus_z> any reference for that runways concept?
14:21:43 <ndipanov> markus_z, try to search openstack-dev archive
14:21:48 <johnthetubaguy> markus_z: no but, lets move on for now
14:21:57 <johnthetubaguy> #link https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items
14:22:07 <johnthetubaguy> so lots of us agreed to do things at the summit
14:22:08 <johnthetubaguy> some of that is happening
14:22:17 <johnthetubaguy> some of that is getting updated above
14:22:40 <johnthetubaguy> given the deadline is making no difference, I am moving it to the midcycle where we can review the list
14:22:47 <bauzas> markus_z: https://review.openstack.org/#/c/112733/
14:22:52 <johnthetubaguy> OK so next thing...
14:23:08 <markus_z> bauzas: thanks
14:23:45 <johnthetubaguy> markus_z: so thats not the full story there, but we should get something written up about that, but I am trying to move on from that, so I am going to stop talking about that now, honest
14:23:48 <mriedem> bauzas: markus_z: actually https://review.openstack.org/#/c/115410/
14:24:03 <bauzas> markus_z: my bad https://review.openstack.org/#/c/115410/
14:24:08 <bauzas> jinxed by mriedem
14:24:16 <ndipanov> but do check out the ML thread too
14:24:17 <mriedem> i am owed one coke
14:24:29 <mriedem> le coke
14:24:33 <johnthetubaguy> mriedem: indeed you are
14:24:40 <bauzas> mriedem: le coca cola, please
14:24:49 <johnthetubaguy> so I am going to change the agdenda from the plan
14:24:51 <johnthetubaguy> #topic Bugs
14:24:56 <johnthetubaguy> so how are we looking with bugs?
14:25:04 <bauzas> nothing really bad
14:25:07 <mriedem> https://review.openstack.org/#/c/194843/
14:25:13 <mriedem> needs reviews for a long standing gate bug ^
14:25:39 <mriedem> had a +2 from sdague yesterday morning before i added more tests and a co-author ack
14:25:55 <johnthetubaguy> ah, nice to keep moving forward on that
14:26:19 <bauzas> we are just struggling providing more trivial bugs, I guess due to the specs reviewing effort
14:26:37 <johnthetubaguy> bauzas: providing? you mean the list has run dry?
14:26:40 <bauzas> so hopefully it should resume by the next weeks
14:26:44 <mriedem> https://bugs.launchpad.net/nova/+bugs?orderby=-importance&start=0
14:26:47 <mriedem> i don't see any critical bugs
14:26:51 <mriedem> several high severity
14:26:53 <bauzas> johnthetubaguy: yup, we only identified a few of them
14:26:54 <mriedem> so fix bugs
14:26:55 <mriedem> thanks
14:26:58 <johnthetubaguy> yes
14:27:01 <ndipanov> I'd plug my series - https://review.openstack.org/#/c/180637/
14:27:03 <johnthetubaguy> the next few topics are all specs
14:27:13 <johnthetubaguy> #topic stuck spec reviews
14:27:14 <sdague> mriedem: I'll go look at the patch again
14:27:17 <bauzas> mriedem: right, none in the client too
14:27:32 <johnthetubaguy> https://review.openstack.org/#/c/192675/6/specs/liberty/approved/vmware-limits.rst,cm
14:27:36 <ndipanov> mriedem, please check it out - it may fix a bunch of problems with volumes
14:27:42 <ndipanov> and it's been sitting there
14:28:02 <scheuran> https://review.openstack.org/#/c/182280/ - my spec is stuck - as there's no clear strategy on how to get a new vif_type in due to the ongoing os-vif-library discussions
14:28:15 <ndipanov> johnthetubaguy, https://review.openstack.org/#/c/193576/ <- has buy in from jaypipes and dansmith and is kind of a priority
14:28:28 <scheuran> can anyone make a statement on how to proceed?
14:28:29 <bauzas> didn't we agreed to rename 'stuck' into 'controversial' or whatever else less subject to confusion ?
14:28:31 <mriedem> scheuran: i +1ed your spec on the assumption that os-vif won't make liberty
14:28:36 <johnthetubaguy> so the issue is, vmware can't just straight copy the libvirt established settings
14:28:48 <jdurgin> https://review.openstack.org/#/c/188244/ <- approach seems agreed upon, just needs final reviews
14:28:57 <garyk> correct - the VC has different interfaces for that
14:29:00 <johnthetubaguy> ndipanov: agreed its good, but this is stuck specs
14:29:13 <garyk> the question is how can we support different mechanism for different drivers to explse things
14:29:16 <ndipanov> not stuck so sorry
14:29:55 <mriedem> jdurgin: get jbernard to review your rbd snapshots spec, i think jbernard is the tagged rbd triage guy
14:29:58 <garyk> i think that we have digressed - can we get back to the limits if possible?
14:30:08 <jaypipes> jdurgin: gah, sorry, I still owe you a review on that :(
14:30:13 <sahid> have spec about console here https://review.openstack.org/#/c/165838/ - stuck with a debate about why we should or not continue to support memecached
14:30:18 <johnthetubaguy> garyk: +1
14:30:23 <garyk> johnthetubaguy: it kind of seems like it is not of interst to anyone - so how can we proceed?
14:30:33 <sahid> s/memecached/memcached
14:30:37 <johnthetubaguy> so there are two ways forwards with limits
14:30:49 <johnthetubaguy> sahid: please hold while we deal with the ones on the agenda
14:30:59 <sahid> oops
14:31:04 <johnthetubaguy> we just merge the hypervisor specific stuff
14:31:07 <johnthetubaguy> or
14:31:20 <johnthetubaguy> we come up with an interface that works across all hypervisors
14:31:27 <johnthetubaguy> now that later bit is hard, as we know
14:31:39 <johnthetubaguy> my problem is really with what the end user has to know about
14:31:56 <johnthetubaguy> it all boils down to the write up I am trying to do on flavor extra specs, image props, etc, etc
14:32:02 <garyk> my take is that the admin knows which backend divers she/he has running and they provision accordingly
14:32:13 <johnthetubaguy> we are in a mess and need to dig oursleves out of a whole there
14:32:25 <johnthetubaguy> so the admin side is different
14:32:38 <johnthetubaguy> there are times where we *might* not be able to isolate those folks from differences
14:32:46 <johnthetubaguy> and well, thats the sad reality
14:32:53 <garyk> and we keep on digging - here is an example of one that was approved for libvirt which is on similar lines and the other drivers may have different ways of exposing - https://github.com/openstack/nova-specs/commit/3b32baa07a50536b31362e683d82c66bbe8aca88?
14:32:56 <johnthetubaguy> but the problem is when users get to see the differences
14:33:35 <garyk> yes, i understand that. bt an admin could maybe filter them for displaying to the users according to the volume type seletced
14:33:37 <ndipanov> johnthetubaguy, the force detach is pretty stuck
14:33:37 <johnthetubaguy> OK so what do we do?
14:33:45 <ndipanov> once you're done with this one
14:33:45 <johnthetubaguy> block this or not?
14:34:06 <garyk> i am in favor of not (but i have already thrown my toys out of the cradle today at least once)
14:34:10 <jaypipes> ndipanov: I am super -1 on the force detach thing.
14:34:37 <johnthetubaguy> garyk: so given no one is siding, I need to make a call and give you answer on the spec
14:34:39 <ndipanov> I am superer -1 on it
14:34:48 <johnthetubaguy> so the force detach thing
14:34:55 <garyk> johnthetubaguy: ok, thanks
14:34:59 <ndipanov> but would also like to see a solution
14:35:07 <johnthetubaguy> so the issue I have is that how do we solve that problem otherwise?
14:35:09 <johnthetubaguy> ndipanov: +1
14:35:26 <ndipanov> I think make detach volume work better
14:35:37 <johnthetubaguy> in the mean time we have users having to manual edit the DB to fix things up when things go wrong
14:35:40 <ndipanov> no one has come up with a reason why it can't be done
14:35:48 <ndipanov> on that spec
14:35:55 <ndipanov> and some of the proposers agree to that
14:35:59 <ndipanov> but I see no movement
14:36:12 <ndipanov> so maybe a sumary from you would help
14:36:19 <johnthetubaguy> ndipanov: I can try that
14:36:23 <ndipanov> as now it seems like a bunch of ppl disagreeing :)
14:36:29 <johnthetubaguy> ndipanov: if we can make detach just work, I am totally fine with that
14:36:31 <ndipanov> and the proposers don't seem to be updating it
14:36:47 <ndipanov> (maybe they think it already missed the train)
14:36:48 <johnthetubaguy> well I prefer that quite a lot
14:36:53 <ndipanov> me too
14:37:04 <ndipanov> Paul said there may be some caveats
14:37:05 <jaypipes> johnthetubaguy: sorry, I don't care about operators having to temporarily edit the DB tables.
14:37:06 <mriedem> ndipanov: which spec is related to this force detach volume thing?
14:37:09 <johnthetubaguy> now I was worried we didn't want uses doing the "bad" operation
14:37:12 <ndipanov> but never came back
14:37:14 <ndipanov> mriedem, yes
14:37:21 <mriedem> ndipanov: link?
14:37:25 <ndipanov> mriedem, sec
14:37:32 <jaypipes> johnthetubaguy: we need to fix it properly, not cover it up with a hack that will live on ad infinitum in the REST API
14:37:49 <edleafe> jaypipes: +1
14:37:49 <ndipanov> https://review.openstack.org/#/c/84048/
14:38:00 <ndipanov> jaypipes, +1
14:38:05 <ndipanov> mriedem, ^^
14:38:07 <johnthetubaguy> jaypipes: thats certainly my preference, just felt like that wasn't possible
14:38:20 <ndipanov> johnthetubaguy, well no one came back on there to explain why
14:38:40 <jaypipes> johnthetubaguy: it is certainly possible. in fact, I don't really know why this needs to be a spec at all... we just need to fix the detach volume operations to be more tolerant of failures/inconsistencies.
14:38:41 <ndipanov> I think it can be done
14:38:51 <ndipanov> but would require changes to the API
14:38:51 <mriedem> jaypipes: yeah, sounds like a bug
14:38:52 <jaypipes> it's a bug fix.\
14:38:53 <ndipanov> for the better
14:38:56 <johnthetubaguy> #action johnthetubaguy to add summary of the force detach debate on the spec
14:39:10 <mriedem> so we agree that bugs should be fixed? progress!
14:39:12 <ndipanov> Alternatively move it to the ML
14:39:21 <ndipanov> but yeah
14:39:34 <johnthetubaguy> so I think we are saying, go back and try fix it without an API change
14:39:37 <johnthetubaguy> which is cool
14:39:46 <johnthetubaguy> OK, so lets keep moving
14:39:53 <johnthetubaguy> #topic spec-less blueprints
14:40:13 <johnthetubaguy> now we have way more BPs on this list than makes sense for 20 mins
14:40:14 <andrearosa> jsut a note, it was a spec because before the discussion we thiought we ahd to make an API change which requires (not sure if it is still true) a spec
14:40:15 <ndipanov> I brought up a point in response to alaski that
14:40:23 <ndipanov> no one gets pinged when you post a BP
14:40:30 <ndipanov> so ppl default to a spec
14:40:44 <garyk> can we discuss the nsxv neutron support?
14:40:44 <ndipanov> ah you mean review them not talk about process..
14:40:46 <ndipanov> hehe
14:40:48 <garyk> that was on the lis
14:40:53 <garyk> list for the meeting
14:40:55 <ndipanov> sry
14:41:07 <johnthetubaguy> andrearosa: so an API change does need a spec, but lets not go there right now
14:41:08 <johnthetubaguy> so we have a list
14:41:10 <garyk> the problem that we have with this is thet neutron driver was released in K and requires 2 nova patches
14:41:17 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/cache-aware-weigher
14:41:19 <garyk> at the summit i was asked to open a BP.
14:41:24 <thomasem> One of those is the routes_v6 addition to the templating engine for injecting network configuration
14:41:27 <mriedem> heh, there are 9 specless bp's in the meeting agenda
14:41:39 <thomasem> sister patch to this one: https://review.openstack.org/#/c/115409/ basically
14:42:01 <johnthetubaguy> so I don't see how this is going to work in the meeting...
14:42:17 <sahid> johnthetubaguy: about this bp the code seems to be close to be ready
14:42:40 <thomasem> hmmmm
14:42:40 <johnthetubaguy> so looking at the list, do any of these right alarm bells for folks?
14:42:52 <mriedem> garyk: there are 2 other specs up for adding new neutron vif type support to nova
14:42:59 <mriedem> seems the nsx thing would be no different right?
14:43:08 <mriedem> they are pretty mechanical though, so it's mostly just docs
14:43:12 <sahid> and i guess makes sense to schedule guest according cached images
14:43:19 <garyk> mriedem: it is different - it is not related to the vif
14:43:29 <bauzas> johnthetubaguy: https://blueprints.launchpad.net/nova/+spec/cache-aware-weigher doesn't require a spec IMHO, since it doesn't change the scheduler interface
14:43:33 <garyk> the neutron driver needs to know the port index to enable the security groups to work
14:43:41 <garyk> that information is only available from nova
14:43:45 <johnthetubaguy> bauzas: that was my take, sound like thats good
14:43:48 <sahid> bauzas: yep it does not require
14:44:00 <garyk> mriedem: https://review.openstack.org/147126
14:44:04 <bauzas> johnthetubaguy: it just adds a new monitor, and take the metrics info in the weigher
14:44:43 <johnthetubaguy> OK I think I am OK with all of these given when I last looked at them
14:44:55 <johnthetubaguy> as before, if there are big issues, we can go though that in the code reviews
14:45:02 <thomasem> great
14:45:02 <sahid> cool
14:45:03 <thomasem> :)
14:45:09 <johnthetubaguy> but I want to give folks the chance to raise concerns here
14:45:22 <johnthetubaguy> I would go through them all, but there are way too many for that to be practical
14:45:26 <thomasem> lol
14:45:41 <johnthetubaguy> now as normal, folks can -2 the patch if it turns out this was all dumb
14:46:01 <garyk> can we discuss https://blueprints.launchpad.net/nova/+spec/vmware-nsxv-support
14:46:02 <bauzas> https://review.openstack.org/#/c/192875/3/nova/cells/filters/different_cell.py,cm doesn't require a spec as well IMHO - again, no change in the cells scheduler if
14:46:26 <johnthetubaguy> garyk: we can, what your concern with that one?
14:46:45 <garyk> johnthetubaguy: is that it is blocked, and we need to have it for K.
14:47:02 <garyk> that is we ship a neutron plugin that does not work as it is lacking this patch
14:47:16 <garyk> and it looks like it swill not in L either as it is -2
14:47:27 <garyk> at the summit i brough this up and you guys asked me to write a BP.
14:47:46 <garyk> so i am still stuck …
14:47:56 <johnthetubaguy> garyk: to get the BP approved you add it to the meeting list
14:48:08 <garyk> i did
14:48:13 <johnthetubaguy> garyk: I just said if there are no concerns I will approve all these
14:48:25 <garyk> ah, ok. missed and misunderstood that
14:48:28 <garyk> thanks
14:48:48 <johnthetubaguy> Ok, no worries
14:48:53 <johnthetubaguy> #topic Open Discussion
14:49:03 <johnthetubaguy> So I think we got to the end of the agenda
14:49:13 <mriedem> cells voting job
14:49:27 <johnthetubaguy> mriedem: good question, that seems like we are good to vote now right?
14:49:38 <mriedem> as in, do we make cells job voting for nova regardless of tempest changes gated on the cells job
14:49:54 <johnthetubaguy> right
14:49:55 <mriedem> johnthetubaguy: we need this first https://review.openstack.org/#/c/194410/
14:49:57 <sdague> mriedem: given that nova owns the regex in tree, I think it's fine
14:49:59 <bauzas> there was a discussion about regression excedptions
14:50:08 <mriedem> sdague: we still need https://review.openstack.org/#/c/194410/ to use the regex in nova's tree
14:50:14 <johnthetubaguy> sdague: mriedem: +1
14:50:16 <bauzas> +1
14:50:17 <mriedem> sdague: shall i harass some -infra people?
14:50:24 <sdague> mriedem: yeh
14:50:25 <johnthetubaguy> I think once we have that patch in, we are good to go
14:50:31 <sdague> I'm +2 on that change already
14:50:40 <rgerganov> johnthetubaguy: can we discuss https://review.openstack.org/#/c/148509/
14:50:52 <bauzas> melwitt just has to rebase her change to be on top of that
14:50:57 <melwitt> I also have a question for open discussion
14:51:15 <andreykurilin> and I :)
14:51:21 <mriedem> -infra has been harassed
14:51:28 <rgerganov> I put mine in the agenda :)
14:51:33 <johnthetubaguy> mriedem: cool, so I think we are good for the cells thing?
14:51:40 <johnthetubaguy> rgerganov: sorry, I am loosing track here, you are next
14:51:44 <mriedem> johnthetubaguy: once the pieces are in place yes
14:51:49 <johnthetubaguy> mriedem: awesome
14:52:03 <johnthetubaguy> big thank you for that work, its great to see us finally get those tests running
14:52:09 <rgerganov> so there is some disagreement on the implementation for the console API change
14:52:13 <johnthetubaguy> I mean four release late, but its happening, so thats awesome
14:52:19 <rgerganov> even though the spec was approved by the API WG
14:52:22 <johnthetubaguy> rgerganov: so is this about removing an API in a microversion?
14:52:28 <rgerganov> johnthetubaguy: yes
14:52:52 <johnthetubaguy> rgerganov: what do you mean by approve by the API WG?
14:52:54 <sdague> rgerganov: so I think that's fine, users calling an old version will still get the old API
14:53:10 <rgerganov> johnthetubaguy: https://review.openstack.org/#/c/185844/
14:53:18 <rgerganov> it explicitly says that we remove the old APIs
14:53:25 <johnthetubaguy> rgerganov: I see you comment in the spec now, sorry
14:53:46 <rgerganov> so I need to chase Kenichi to remove his -1
14:54:04 <johnthetubaguy> rgerganov: have you sent an email to kenichi about that?
14:54:17 <rgerganov> johnthetubaguy: no, but I will do if needed
14:54:31 <johnthetubaguy> rgerganov: thats a good idea if he is not responding
14:54:40 <johnthetubaguy> having said that, it seems like we have support for that approach here
14:54:49 <johnthetubaguy> sdague: are you good to review and possibly +1 that?
14:54:56 <rgerganov> ok, I just need to make sure the other cores are OK
14:55:02 <sdague> johnthetubaguy: yeh, I just +2ed that patch, I'm fine with that approach
14:55:08 <rgerganov> sdague: thanks
14:55:12 <sdague> I feel that is one of the reasons we created microversions
14:55:17 <johnthetubaguy> sdague: awesome, thanks, just saw the update
14:55:28 <johnthetubaguy> rgerganov: thanks for raising that, hopefully that works now
14:55:40 <rgerganov> johnthetubaguy: yup, much appreciated!
14:56:00 <scheuran> I still have the question if it's possible to get new vif_types approved in liberty? Or if all of them are "stuck" due to ongoing discussions regarding os-vif-library?
14:56:20 <mnestratov> johnthetubaguy: about parallels/virtuozzo driver feature parity changes - we have some small fixes and they don't have enough attention. is is possible to look at them somehow?
14:56:32 <melwitt> I wanted to make sure all is well for https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api considering the quotas simplification isn't happening this cycle, that this nested quota isn't going to be blocked
14:56:33 <johnthetubaguy> scheuran: you were first
14:56:48 <neiljerram> scheuran: +1
14:56:51 <johnthetubaguy> melwitt: I have a todo from the summit on that, I think, or someone does
14:57:20 <mriedem> scheuran: in my opinion we shouldn't block new vif type support on the os-vif library proposal for liberty
14:57:27 <johnthetubaguy> melwitt: we were going to check if it was orthognal, if the quota simplicifation was going to happen, or something like that
14:57:50 <snikitin> I have a question about instance tags spec https://review.openstack.org/#/c/177112/ Is it possible to merge it in Liberty?
14:57:50 <johnthetubaguy> mriedem: so I think we need to move forward with the VIF situation, and thats probably going to be the only way to make progress
14:57:57 <neiljerram> I really think that https://review.openstack.org/#/c/193668/ could be approved.  From my reading of comments, no one has any high level objections; just details that could be sorted out during coding.
14:58:03 <mriedem> i thought we said that for nested quotas, expect things to change massively with the quote refactor
14:58:23 <neiljerram> (That's the os-vif-library spec)
14:58:27 <mriedem> johnthetubaguy: the os-vif spec came in pretty late thoguh, and can be worked in parallel
14:58:49 <johnthetubaguy> mriedem: which bit can be worked in parallel again?
14:58:55 <mriedem> we're talking about writing a new library and then integrating that in nova and neutron in liberty yet
14:59:02 <mriedem> i don't see that happening
14:59:10 <johnthetubaguy> mriedem: oh I see now
14:59:13 <mriedem> the people that have new vif types could just get them into nova in liberty the old way
14:59:16 <mriedem> which is fairly mechanical
14:59:24 <johnthetubaguy> so my take, mostly as we are out of time
14:59:35 <scheuran> mriedem: +1
14:59:50 <johnthetubaguy> mriedem: OK, thats cool
14:59:54 <neiljerram> I disagree that we couldn't get this done in L
15:00:01 <johnthetubaguy> if we don't *need* to block people, we really really should not
15:00:07 <neiljerram> Lots of folk interested in helping with this.
15:00:14 <edleafe> johnthetubaguy: yeah - let' em try for L
15:00:26 <johnthetubaguy> neiljerram: I think we are saying lets try to do it in parallel
15:00:29 <mriedem> neiljerram: i'm saying, start working on it
15:00:30 <edleafe> if they don't make it, so be it.
15:00:34 <mriedem> neiljerram: but don't block others for it
15:00:35 <scheuran> johnthetubaguy: ok, meaning I could get a vif_type in in the old way for Liberty?
15:00:41 <johnthetubaguy> scheuran: yes
15:00:50 <scheuran> johnthetubaguy: great!
15:00:50 <johnthetubaguy> OK, seems we are out of time
15:00:54 <neiljerram> That works for me
15:00:57 <mriedem> bye!
15:00:59 <johnthetubaguy> thanks for turning up
15:01:01 <bauzas> +
15:01:08 <scheuran> bye
15:01:12 <johnthetubaguy> #endmeeting