20:59:56 #startmeeting nova 20:59:57 o/ 20:59:57 Meeting started Thu Jun 18 20:59:56 2015 UTC and is due to finish in 60 minutes. The chair is mikal. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:59:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:00 The meeting name has been set to 'nova' 21:00:12 #topic Release status 21:00:16 ohi 21:00:26 o/ 21:00:28 o/ 21:00:28 So the first thing on the agenda for today is release status stuff. 21:00:34 Liberty-1 is somewhere between 23 and 25 June 21:00:38 o/ 21:00:45 And is the deadline for spec approval for non-priority work 21:00:54 o/ 21:00:58 Thanks to those who helped out on spec review day 21:01:06 But we do need to keep focus on spec review for just a little bit longer 21:01:25 I see there are a lot of specs with negative feedback for example, which probably means their authors need to take another look at them 21:01:39 \o 21:01:44 Any other thoughts on spec reviews before we move on? 21:02:14 :/ 21:02:28 Ok, John also wanted me to remind y'all about liberty priorities 21:02:35 #link https://etherpad.openstack.org/p/liberty-nova-priorities-tracking 21:02:44 o/ 21:02:48 There are specs on there as well as code, so its relevant to the current spec review push as well 21:02:53 the trivial bug review list has been languishing 21:02:55 on the etherpad 21:03:10 mriedem: correct 21:03:12 o/ 21:03:17 mriedem: that's probably true. I feel like all I've had time for myself is spec reviews. 21:03:17 how do we handle stuck spec reviews….either talk about them in sub-project meetings or anything else because contacting the person whom you might want the spec to get reviewed might be already swapmed with other specs 21:03:19 i blame bauzas' baby 21:03:34 mriedem: blame rather some spec implem... 21:03:44 vilobhmm1: it depends why its stuck I suppose. Is there disagreement, or just a reviewer gone AWOL? 21:03:58 vilobhmm1: I don't think yours is stuck 21:04:05 it's just not getting a lot of action 21:04:11 stuck means contention 21:04:21 o/ 21:04:36 o/ 21:04:53 Yeah, so it there's no unsolvable dispute on the review, I think its just reviewers being buried 21:04:56 dansmith : ok…but in that case as well attending sub -rpoejct meeting is a better option ? 21:04:56 "just" 21:05:03 yep 21:05:05 I don't have a good fix for that apart from patience unfortunately 21:05:14 vilobhmm1: sounds good 21:05:24 bauzas : ok 21:05:29 vilobhmm1: yeah, a heap of +1s from respected sub-team members never hurts 21:05:40 Anything else on specs before we move on? 21:05:41 mikal : sure…thanks 21:06:03 #topic Summit followup 21:06:04 what about the nova instance user spec? I think most of the barbican and keystone folks are on board now, but have heard very little from nova reviewers. 21:06:16 #undo 21:06:17 Removing item from minutes: 21:06:27 kfox1111: got a review link? 21:06:32 yup. just a sec. 21:06:46 https://review.openstack.org/#/c/186617 21:07:08 kfox1111: not stuck 21:07:11 the 23'rds getting really close. 21:07:11 just not getting attention 21:07:41 Well, its got a lot of detailed review comments in the past 21:07:53 Two on the 18th even 21:08:00 I think we just need to let that one go through the process 21:08:14 Is there a way to partially approve it so that it can continue past the 23rd? 21:08:26 kfox1111: that is a question from johnthetubaguy 21:08:35 kfox1111: if the barbican and keystone people are on board why aren't they +1 on it? 21:08:39 kfox1111: I recommend emailing him, but I am unaware of a plan for spec freeze exceptions 21:08:58 kfox1111: i only see your +1 on your own spec :) 21:09:13 mriedem: because we've been discussing it in channels. 21:09:37 mriedem: kfox1111 has been really good about involving us, I have not read the final (current) spec version as I wasn't aware it was ready 21:09:38 morganfainberg: that's not very visible to us though, could you get some peeps to do a review in gerrit please? 21:09:40 ok, well, i'd consider some weight from the security minded people to be helpful in the outcome of that spec 21:10:03 if that helps why we haven't specifically +1'd 21:10:10 or at least why i haven't 21:10:27 mikal: yes. i'll try and wrangle people 21:10:38 morganfainberg: thanks, I think that will help 21:10:38 morganfainberg: thanks. 21:10:43 mriedem: good thinking 21:10:44 at least from the keystone side (i make no claims about wrangling barbican folks) 21:10:49 mriedem: you brained that well 21:11:19 more compliments please 21:11:20 thanks 21:11:23 Heh 21:11:32 Ok, anything else on specs and release status? 21:11:33 I'll try and motivate the barbican side. :/ 21:11:35 thanks. 21:11:59 ...nothing... 21:12:06 #topic Summit follow ups 21:12:23 John also wants to remind us that the etherpad of summit action items exists 21:12:30 #link https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items 21:12:42 And that the due date for action items is liberty-1 unless otherwise states 21:12:47 So that's like next week people 21:12:54 I propose we all panic and run around in circles 21:13:00 second 21:13:03 Oh JOhn's going to be busy then ;P 21:13:05 oh 21:13:06 Or assign our action items to someone else 21:13:09 really? 21:13:11 * morganfainberg panics and runs in circles 21:13:16 i honestly though l-1 was spec proposal freeze, not approval 21:13:17 but ok 21:13:33 mriedem: no, approval IIRC 21:13:41 I have been wrong before, but I don't think is one of those times 21:13:53 So... Do your action items people! 21:13:56 Or assign them to sdague! 21:14:15 Does anyone want to talk more about action items apart from being reminded they exist? 21:14:24 i've assigned all of my mq devstack plugin work to sdague already 21:14:34 haha 21:14:35 mriedem: so noted 21:14:45 just the fact that l-1 sounds great for engaging actions, not resolving them IMHO 21:14:56 mriedem: too soon 21:14:59 bauzas: I think we take it on a case by case basis 21:15:05 just because some of them are just so huge that they can't be done that quick 21:15:13 bauzas: we do need to get moving on them though, as we only get busier from here 21:15:16 yeah, that's my thouhgt 21:15:32 bauzas: I think just do your best and keep the status updated in the etherpad 21:15:35 I mean I understand john, he wants to make sure people are committed 21:15:43 We couldn't possibly do the _reviews_ for all of them if they got done in time 21:15:52 So I think we just accept its a goal we aspire to but wont meet 21:16:27 fair point 21:16:37 Let's move on 21:16:46 #topic Non-spec reviews to discuss 21:16:54 #link https://blueprints.launchpad.net/nova/+spec/consolidate-libvirt-fs-volume-drivers 21:16:57 that's mine 21:17:06 Is this BP trivial? 21:17:09 basically refactor the libvirt volume driver stuff into separate modules, 21:17:11 Do we approve it without a spec? 21:17:17 and extract a common base class for the file system drivers 21:17:35 the bp is really just for bookkeeping 21:17:40 I though the view from the m/l was no spec needed 21:17:41 It seems sane to me 21:17:45 Which I think I said on the thread as well 21:17:48 tonyb: it was from danpb 21:17:52 tonyb: no spec, still needs a bp 21:18:23 was the config question resolved in the ml? 21:18:29 alaski: yeah, no config option chagnes 21:18:32 b/c cinder multi backend 21:18:35 okay 21:18:36 my bad. I blame the lack of coffee 21:18:41 then I'm +1 on bp only 21:18:54 So, I am go to approve this... 21:18:58 Any objections? 21:19:19 none 21:19:29 Going... 21:19:34 ...going... 21:19:41 ...gone 21:19:45 danka 21:20:07 #link https://blueprints.launchpad.net/nova/+spec/vmware-limits 21:20:14 This one is the next candidate for non-spec approval 21:20:39 Any thoughts? 21:20:54 there is a spec for it here https://review.openstack.org/#/c/192675/ 21:20:59 so not sure why it's on the list... 21:21:16 yeah there's a spec :-) 21:21:31 Ok, so we want to skip over it here then? 21:21:55 it's proposing flavor extra_spec additions, I would prefer the spec 21:22:06 Ok, works for me 21:22:06 there are a handful of changes to the code 21:22:08 with several docimpacts 21:22:15 one of the patches for that has a +2 but the spec isn't approved yet? 21:22:29 melwitt: time for a procedural -2? 21:22:30 melwitt: feel free to procedural -2 21:22:40 +1 for -2 21:22:46 okay 21:22:52 melwitt: first -2? 21:22:54 -2++ 21:22:57 awwwww 21:23:02 melwitt: if so, savor it slowly 21:23:09 Heh 21:23:12 I'm a bit confused by the limits stuff but let's discuss in the spec 21:23:14 :P 21:23:28 Ok, let's move on 21:23:33 #topic Stuck spec reviews 21:23:42 #link https://etherpad.openstack.org/p/liberty-nova-priorities-tracking 21:23:51 That URL lists some classes of "stuck spec" 21:24:16 (at the end, but the list is long) 21:24:46 I'm not really sure how we progress those in this meeting 21:24:53 Except for making sure people are aware of them 21:25:03 For example, I was on that list for a while as blocking things, but didn't realize it 21:25:06 right, I missed that 21:26:02 So, I guess this is mostly just drawing that to people's attention unless we have other ideas for how to progress it 21:26:11 well, if there is any spec owner, with spec on that list, they should speak up? 21:26:14 mmm, most of them are not actually stuck, just waiting reviews 21:26:30 Yeah, some of it is a search for consistency 21:26:40 For example, what bar are we holding volume drivers to? 21:26:43 we need another word for "stuck" 21:26:50 could we just drop the use of word 'stuck' and use 'controversial' instead ? 21:26:52 contended 21:26:55 edleafe: we need more words for stuck 21:27:07 bauzas: +1 21:27:09 We're like eskimos... We need many words for "lost in code review land" 21:27:26 "contented" vs. "stalled" 21:27:27 please pay attention to https://review.openstack.org/#/c/184295/ which is about vzstorage support 21:27:30 inuit 21:27:37 s/contented/contended 21:27:49 * bauzas won't try to provide good wording 21:27:52 mnestratov: its already on the list 21:28:08 But yeah, you get the idea 21:28:18 mnestratov: it's not stuck/contended/deadlocked 21:28:25 mnestratov: address johnthetubaguy's -1 21:28:29 let's move on 21:28:51 ok. I see. it is ready in cinder and was waiting for CI to be run against nova 21:29:01 I'm looking at the two specs listed in the agenda 21:29:04 which is done 21:29:07 And they don't seem particularly stuck to me 21:29:33 So unless someone knows why they're there let's keep going 21:29:48 mriedem: it is addressed 21:29:58 #topic Stable branch status 21:30:03 Anything we need to talk about here? 21:30:08 stable is fine, icehouse last release is tagged and out for testing 21:30:13 icehouse should be eol soon 21:30:24 Cool 21:30:33 #topic Gate status 21:30:35 fine 21:30:36 http://status.openstack.org/elastic-recheck/index.html 21:30:43 #topic Critical bugs 21:30:43 there is one thing with the gate, 21:30:49 #undo 21:30:49 https://review.openstack.org/#/c/192348/ - adds logging for a network race bug 21:30:50 Removing item from minutes: 21:31:10 so eyes on that please since the bug is rare enough to be annoying to track 21:31:15 Ok, I can review that after the meeting 21:31:32 that's it, thanks 21:31:40 #topic Critical bugs 21:31:58 None! 21:31:58 so, zero/zero 21:32:03 Yay! 21:32:13 #topic Open Discussion 21:32:23 Nothing some items for this on the agenda before we free for all 21:32:33 oslo.config auto config generation is dropped 21:32:52 #link https://blueprints.launchpad.net/nova/+spec/oslo-config-generator 21:33:11 Is anyone passionate about this? 21:33:35 mikal: https://review.openstack.org/#/c/180013/ is being held up 21:33:39 Or do we just review the patch for the new oslo way and move on? 21:34:06 which is what i'd prefer needless to say :) 21:34:55 dims: yeah, I think this is a call for someone to work with you on getting that patch (or its replacement) through 21:35:07 dims: is haypo aware of that one ? 21:35:30 mikal: bauzas: yes i can work with haypo, just need agreement that we can get rid of old generator.py from nova 21:35:48 Its in openstack/common, right? 21:35:53 yes 21:36:16 So I feel that if its been removed from the source of that code (i.e. the cut side of the cut and paste), then we have to do something to get rid of it in nova 21:36:23 That might just take some time as we work out what to do 21:37:12 mikal i can take comments and rework the patch, just want to be clear that old one is going away 21:37:22 I'll take a look at the patch later today 21:37:32 dims: yeah, fair enough. 21:37:45 Other oslo things for liberty... 21:37:50 #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/067131.html 21:38:05 John is asking if anyone wants to run with this on the nova side? 21:38:42 Ok, final thing from John... 21:38:53 THe next version of nova, liberty-1, will be 12.0.0b1 21:38:56 mikal: i have been doing the oslo work, haypo is starting to help 21:39:03 Which I like because its easy to pronounce 21:39:07 dims: excellent 21:39:11 And with that 21:39:18 ...Let the open open discussion begin!... 21:39:22 i had one, fix for bug 1464381 should it be a bug fix? (https://review.openstack.org/#/c/191095/) or needs a microversion? (spec - https://review.openstack.org/#/c/191151/) 21:39:24 bug 1464381 in OpenStack Compute (nova) "can't get instances from different tenants even if policy.json is set properly for that" [Medium,In progress] https://launchpad.net/bugs/1464381 - Assigned to Davanum Srinivas (DIMS) (dims-v) 21:39:45 sdague was leaning towards bug fix 21:39:46 dims: i thought sdague said in the spec he didn't think it needed to be a microversion 21:39:57 mriedem: got a contradict from alex 21:39:58 but it's an upgradeimpact / securityimpact on the fix 21:40:01 since the policy has to change 21:40:15 yes, i added those tags to the bug fix 21:40:44 well i guess if you look up 'stuck review' we should just have a pointer to this one then 21:40:46 :) 21:40:55 We have a spec-less feature parity blueprint. AFAIK, parity bps don't need specs. Was hoping it could be approved? https://blueprints.launchpad.net/nova/+spec/hyper-v-block-device-mapping-support 21:40:59 Are sdague and Alex here now? 21:41:05 We could make them... Talk about it 21:41:10 dims: I saw alex_xu's comment but don't yet understand it, so I thought some discussion would ensue 21:41:15 I lean in favor of not needing a microversion 21:41:26 alaski: what about v2, need the fix there too 21:41:27 i also dont think a microversion is warranted here 21:41:44 dims: if there is no microversion then it seems legit to fix in v2 also 21:41:49 we don't have microversions there 21:41:49 So I think you should say all that on the review 21:41:51 Both of you 21:42:04 fair enough 21:42:15 cool, i'll drop the spec 21:42:18 thanks! 21:42:23 claudiub: now you! 21:42:29 yeay! 21:42:41 That bp looks trivial to me 21:42:44 Does anyone disagree? 21:42:46 https://blueprints.launchpad.net/nova/+spec/hyper-v-block-device-mapping-support 21:43:18 not I 21:43:33 I will approve unless someone objects in... 21:43:34 3... 21:43:42 2... 21:43:53 1... 21:44:01 Approved! 21:44:08 another thingy 21:44:14 https://blueprints.launchpad.net/nova/+spec/hyperv-storage-qos 21:44:17 spec was approved 21:44:47 Oh, I can fix that now 21:44:48 actually, mikal approved the spec. :) 21:44:58 Fixed 21:45:06 thanks! 21:45:09 Next! 21:45:22 Nothing else? 21:45:26 Can I have 15 minutes back? 21:45:31 * mikal looks hopeful 21:45:55 Sounds like I can! 21:46:00 See ya all later 21:46:01 fine by me. 21:46:04 o/ 21:46:06 #endmeeting