14:01:40 <russellb> #startmeeting nova 14:01:41 <openstack> Meeting started Thu Apr 3 14:01:40 2014 UTC and is due to finish in 60 minutes. The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:45 <openstack> The meeting name has been set to 'nova' 14:01:52 <russellb> hello! 14:02:05 <russellb> #link https://wiki.openstack.org/wiki/Meetings/Nova 14:02:13 <bauzas> hi 14:02:15 <n0ano> o/ 14:02:15 <mspreitz> o/ 14:02:17 <alaski> hi 14:02:18 <dansmith> yawn 14:02:19 <johnthetubaguy> o/ 14:02:30 <mriedem> hi 14:02:57 <russellb> #topic icehouse-rc 14:03:04 <russellb> #link https://launchpad.net/nova/+milestone/icehouse-rc1 14:03:08 <russellb> we released RC1! \o/ 14:03:18 <russellb> which promply brought up "but what about X?" questions :-) 14:03:28 <russellb> promptly* 14:03:41 <russellb> we have opened up RC2 14:03:51 <russellb> aiming to release ASAP, but certainly by early next week 14:03:56 <russellb> #link https://launchpad.net/nova/+milestone/icehouse-rc2 14:04:35 <russellb> i'd like to discuss any other bugs that you all think we should put on RC2 14:04:47 <russellb> dansmith: have the libvirt xen/lxc one handy? 14:04:55 <dansmith> https://launchpad.net/bugs/1301453 14:05:32 <russellb> dansmith: fix seem safe enough? 14:05:36 <dansmith> yes 14:05:42 <dansmith> I've been working with them on it, 14:05:48 <dansmith> and if they don't fix it up in a couple hours, I'll just do it 14:05:51 <russellb> OK cool 14:05:53 <dansmith> just nits at this point 14:05:57 <russellb> targeted to RC2 then 14:06:00 <dansmith> cool 14:06:37 <russellb> others to consider ... https://bugs.launchpad.net/nova/+bugs?field.tag=icehouse-rc-potential 14:06:44 <russellb> the vmware ones are still blocked on CI 14:06:54 <russellb> the translation one is actually already on RC2 for us 14:06:58 <russellb> so I think we're good on that list 14:07:37 <russellb> other than that, we should consider Fix Committed bugs ... https://bugs.launchpad.net/nova/+bugs?field.status%3Alist=FIXCOMMITTED 14:08:17 <russellb> i'll look over those, but if anyone else wants to, that'd be great 14:08:29 <russellb> and let me know which ones you think are important and safe enough for a backport 14:08:45 <mriedem> trivial but? https://bugs.launchpad.net/nova/+bug/1301384 14:09:06 <mriedem> to avoid the sky is falling when icehouse is released? 14:09:18 <dansmith> https://bugs.launchpad.net/nova/+bug/1291805 14:09:24 <dansmith> I never saw which versions of libvirt that pertained to, 14:09:24 <russellb> mriedem: that one is on RC2 already 14:09:32 <mriedem> russellb: oh ok 14:09:37 <dansmith> but it was trivial and might pick us up some easier support 14:10:04 <russellb> dansmith: commit message made it sound like "Just in case at some point in the future" ... 14:10:09 <dansmith> oh, hmm, danpb's comment in the bug 14:10:16 <dansmith> yeah, hmm, I wonder why that merged then 14:10:32 <dansmith> danpb says "this can never change" 14:10:35 <russellb> good point 14:10:40 <russellb> i +2d it i think 14:10:44 <russellb> but i hadn't seen that comment 14:10:50 <dansmith> maybe they were running a hacked up version 14:10:59 <dansmith> okay, anyway, not for rc2, I just remember seeing the trace 14:11:01 <russellb> guess i just considered it reasonable enough 14:11:07 <russellb> yeah, good thing to consider 14:11:35 <mriedem> https://bugs.launchpad.net/nova/+bug/1254722 shouldn't be fix committed... 14:12:00 <russellb> stab it! 14:12:03 <mriedem> i did 14:12:08 <russellb> excellent 14:12:25 <dansmith> so violent 14:12:53 <russellb> any more questions on Icehouse / RC process for now? 14:13:40 <russellb> #topic blueprints 14:13:49 <russellb> as Icehouse winds down, Juno is picking up 14:13:58 <russellb> master is open for Juno dev 14:14:05 <russellb> and blueprints are flowing in rapidly 14:14:25 <russellb> to recap, juno process is captured here: 14:14:27 <russellb> #link https://wiki.openstack.org/wiki/Blueprints#Creation 14:14:48 <johnthetubaguy> nova-specs seems to have started doing its thing quite well 14:14:49 <russellb> big addition is the added standardization on design spec formatting / location / review 14:14:51 <johnthetubaguy> template structure should be fixed now, for J-1 at least I guess? 14:15:04 <russellb> #link https://review.openstack.org/#/q/status:open+project:openstack/nova-specs,n,z 14:15:09 <russellb> ^^^ all open spec reviews 14:15:16 <russellb> would love to see lots of participation on those 14:15:31 <russellb> hopefully it's easier to participate in spec reviews now that we're using gerrit 14:15:47 <russellb> so put it in your code review queries :-) 14:16:24 <russellb> any questions about the process? 14:16:32 <russellb> or specs folks would like to discuss now? 14:16:56 <johnthetubaguy> maybe API specs, and if we should delay review until the summit 14:17:14 <johnthetubaguy> it feels quite a long way away 14:17:14 <russellb> my opinion on that is it's case by case, and not much different than other things 14:17:24 <russellb> depends on the size / scale of the impact 14:17:45 <russellb> if it's hugely direction impacting, it makes sense to draw out the discussion, bring it to the ML, have a session on it, make sure the right decision gets made 14:17:54 <johnthetubaguy> so random new API, let people add them, still force v3 and v2? 14:17:57 <russellb> if it's a more straight forward API addition, new extension or whatever, then i don't see any reason to delay 14:18:09 <dansmith> agreed 14:18:11 <russellb> i think policy for icehouse was force v3, allow v2 14:18:20 <russellb> which in practice means they'll do both 14:18:26 <russellb> usually 14:18:34 <johnthetubaguy> right, thats what I meant, oops 14:18:40 <johnthetubaguy> seems good to me 14:18:43 <russellb> cool 14:19:53 <russellb> other blueprint process thing ... we need to nail down the process around when blueprints get targeted 14:20:06 <russellb> i don't think we have that clarified on the wiki page yet 14:20:20 <johnthetubaguy> russellb: +1 14:20:46 <johnthetubaguy> we spoke about waiting for first patch, post approval, before targeting? 14:20:53 <rushiagr> ls 14:21:00 <russellb> yes, and i think that makes sense 14:21:07 <russellb> folks are going to target things anyway 14:21:08 <dansmith> I think we should be less specific about "first patch" 14:21:29 <russellb> so maybe like before, "ignore unapproved / unprioritized stuff" on the lists for the most part 14:21:30 <dansmith> and just say something like "code such that we think the proposed target is achievable" 14:21:45 <russellb> and we don't mark it approved / prioritized until the code requirement is met? 14:22:08 <johnthetubaguy> yup, that makes, no approval till the target looks achievable 14:23:02 <russellb> johnthetubaguy: want to take a stab at updating the wiki to reflect when we'll approve/set priority? 14:23:13 <johnthetubaguy> russellb: sure, will do 14:23:32 <russellb> k, then make sure all nova-drivers is aware of what got written down so we're all following the same rules 14:23:39 <johnthetubaguy> dansmith: will take your proposed phrase, that sounds good 14:23:44 <dansmith> johnthetubaguy: cool 14:23:47 <russellb> +1 14:23:55 <dansmith> johnthetubaguy: no charge for that one, this time 14:24:00 <johnthetubaguy> russellb: still a launchpad list I can mail I guess? 14:24:05 <johnthetubaguy> dansmith: cool :) 14:24:10 <russellb> johnthetubaguy: yes 14:24:14 <russellb> for now anyway 14:24:30 <russellb> worth noting that we actually have 2 teams now, that are identical for now 14:24:41 <russellb> we have nova-drivers on launchpad, that has blueprint management permissions 14:24:45 <russellb> and nova-specs-core in gerrit 14:25:18 <russellb> should stay the same until we have a really good reason not to 14:25:26 <russellb> but just fyi i guess ... 14:25:34 <johnthetubaguy> one more question on that 14:25:50 <johnthetubaguy> if you miss a milestone, do we re-approve, maybe thats overkill? 14:26:09 <russellb> hmm, not the spec, i think that would be overkill 14:26:28 <russellb> i think we just re-evaluate its "likely to make it" status 14:26:31 <russellb> and maybe adjust priority 14:26:40 <russellb> or un-approve, depending 14:26:49 <johnthetubaguy> oh, I mean the blueprint 14:26:57 <dansmith> I think just auto retargeting for the next milestone has shown not to work very well 14:26:57 <johnthetubaguy> in launchpad 14:26:59 <russellb> if something slips from Juno to K, I think we should re-approve specs at that point 14:27:18 <johnthetubaguy> russellb: spec definitely for release slip 14:27:29 <johnthetubaguy> dansmith: yeah, auto slip has gone badly 14:28:22 <russellb> so how do we improve? 14:28:35 <russellb> is re-evaluate "likelihood to make it" on deferral good enough? 14:28:57 <dansmith> I dunno, 14:29:01 <russellb> gets overwhelming when we're deferring 100 things 14:29:06 <dansmith> I hope that the list is smaller, 14:29:10 <dansmith> so that it's easier to manage 14:29:16 <alaski> +1 14:29:16 <russellb> but then again, we're drastically rate limiting "crap" via the specs review 14:29:17 <dansmith> and we can just make more intelligent decision 14:29:18 <dansmith> s 14:29:30 <russellb> agree 14:29:40 <russellb> a lot fewer blueprints should make it that far 14:29:47 <johnthetubaguy> yeah, makes sense 14:29:48 <dansmith> hopefully 14:29:48 <alaski> it seems like re-evaluating on deferral might be a good start, and then improve from there 14:30:44 <russellb> anything else on juno blueprints? 14:30:58 <russellb> thanks again for everyone's work putting this process update together 14:31:00 <russellb> i'm excited about it 14:31:17 <johnthetubaguy> please review: https://wiki.openstack.org/wiki/Blueprints#Nova 14:31:21 <russellb> big improvements every cycle 14:31:41 <johnthetubaguy> (catch me with comments after the meeting on IRC, if thats best) 14:32:15 <russellb> might want to move some of those notes to the next section 14:32:21 <russellb> under "Iclusion in the release roadmap" 14:32:37 <russellb> to help make that part stand out 14:32:51 <russellb> #topic open discussion 14:33:03 <russellb> last thing i had was noting that PTL nominations are open 14:33:05 <russellb> I'm not running 14:33:07 <johnthetubaguy> russellb: thanks will take a peek 14:33:14 <russellb> and i just wanted to say a big thanks to those that have stepped up to run 14:33:30 <russellb> really makes me feel good to have great leaders ready to take over 14:34:20 <mriedem> russellb: thanks for the, you know, leadership - i'm not good with compliments 14:34:29 <mriedem> level-headedness 14:34:40 <russellb> heh, thanks :) 14:34:47 <russellb> i'm not planning on going anywhere really 14:34:54 <russellb> other than taking some time off 14:35:04 <russellb> and maybe broaden focus a little bit 14:35:35 <mspreitz> I have a topic 14:35:39 <russellb> mspreitz: sure, what's up 14:35:44 <mspreitz> holistic scheduling API 14:35:53 <mspreitz> at the last summit, I remember two negatives... 14:36:00 <mspreitz> 1 - inclusion of orchestration 14:36:02 <mspreitz> 2 - complexity 14:36:06 <mspreitz> I understand 1 and agree 14:36:12 <mspreitz> I am not sure what was meant by 2 14:36:22 <russellb> well, part of it i think is about taking baby steps 14:36:31 <johnthetubaguy> mspreitz: have you seen this effort: https://review.openstack.org/#/c/82133/ 14:36:32 <russellb> i felt like the simpler instance groups was a reasonable icehouse target 14:37:02 <mspreitz> johnthetubaguy: I saw it but have not had time to study it yet 14:37:04 <bauzas> mspreitz: I guess this topic would need to be covered at the weekly Gantt meeting 14:37:05 <russellb> sometimes things are so big that they're completely unreasonable without being broken down into concrete things that can be achieved 14:37:18 <mspreitz> OK, sure, understand a roadmapping idea 14:37:19 <devoid> I still do not understand why it's called a scheduler, placement-maker is more appropriate. 14:37:20 <mspreitz> completely agree 14:37:26 <russellb> johnthetubaguy: i need to re-review that, had some concerns ... 14:37:33 <mspreitz> completely agree with roadmapping 14:37:58 <mspreitz> on terminology: what do you guys mean by "scheduling" that is not "placement" ? 14:38:01 <russellb> i think in general, in terms of the scheduler, project priorities are around decoupling from nova right now 14:38:01 <johnthetubaguy> russellb: likewise, I need to re-review that 14:38:05 <bauzas> russellb: your comments will be welcome :) 14:38:14 <mspreitz> I know climate means true scheduling, but other than that... 14:38:18 <russellb> bauzas: assume you updated based on my comments? 14:38:26 <devoid> if you look at acm papers, scheduling is place x time decisions. 14:38:27 <bauzas> russellb: indeed 14:38:34 <russellb> bauzas: cool 14:38:36 <n0ano> mspreitz, do you have a link for a BP about this? 14:38:40 <mspreitz> devoid: exactly. Until climate, there was no time 14:38:43 <bauzas> russellb: I rewrote the problem statement 14:38:51 <russellb> heh, well, there may be a better name, but "scheduler" is pretty ingrained as openstack terminology at this point 14:38:53 <russellb> bauzas: cool 14:39:41 <bauzas> mspreitz: devoid: there is a summit proposal 14:39:42 <mspreitz> OK, if no more specific complaints than the need for realistic roadmapping, I understand and agree 14:39:56 <russellb> realistic roadmapping is part of it 14:40:02 <bauzas> mspreitz: devoid: http://summit.openstack.org/cfp/details/45 14:40:03 <russellb> also needs to align with other current priorities 14:40:11 <russellb> (decoupling scheduler to prepare to split it out) 14:40:54 <mspreitz> BTW, now that Docker has given up on being in nova, that's more pressure for common scheduling 14:40:56 <bauzas> russellb: +1 14:41:05 <russellb> mspreitz: disagree with that comment 14:41:19 <mspreitz> russellb: how so? 14:41:23 <russellb> the nova docker driver is still under development 14:41:42 <russellb> just moved to a stackforge repo 14:41:49 <russellb> it still exists as it did, location moved 14:41:52 <mspreitz> russellb: got it 14:43:10 <russellb> for reference: http://git.openstack.org/cgit/stackforge/nova-docker 14:43:36 <johnthetubaguy> a separate scheduler seems an easier place to consider volumes and networks when doing placement, so it might be worth waiting a little on that 14:43:49 <russellb> right 14:43:57 <mspreitz> johnthetubaguy: agree, that's why things are ordered as they are 14:44:35 <russellb> reasonable goal for juno seems to be - decouple from nova db 14:44:38 <johnthetubaguy> mspreitz: cool, just wanted to point at the elephant in the room, glad we are agreed there :) 14:44:40 <russellb> that's going to be big enough 14:44:54 <russellb> IMO 14:44:58 <bauzas> russellb: +1 14:45:01 <mspreitz> russellb also needs to align with other current priorities 14:45:08 <mspreitz> can you elaborate? 14:45:08 <johnthetubaguy> russellb: +1 14:45:20 <russellb> mspreitz: the stuff i was just saying, basically 14:45:28 <mspreitz> OK, thanks 14:46:15 <russellb> unfortunately a lot of more mechanical refactoring and reworking of the scheduler as-is needed before the more "fun" stuff can be done 14:46:40 <bauzas> hence the blueprint :) 14:46:46 * russellb nods 14:47:07 <russellb> baby steps! 14:47:48 <russellb> any other topics for today? 14:48:58 <russellb> alright then, thanks everyone! 14:49:02 <russellb> #endmeeting