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