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