14:00:04 <johnthetubaguy> #startmeeting nova
14:00:04 <openstack> Meeting started Thu Oct  2 14:00:04 2014 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:08 <openstack> The meeting name has been set to 'nova'
14:00:14 <dansmith> o/
14:00:26 <boden> \o
14:00:33 <edleafe> \o
14:00:38 <alaski> hi
14:00:41 <mriedem> hi
14:00:47 <johnthetubaguy> #topic Juno Status
14:00:47 <leifz> o/ lurking.
14:00:49 <bauzas> \o
14:00:53 <johnthetubaguy> so we have RC1 cut
14:00:58 <n0ano> o/
14:01:23 <johnthetubaguy> https://bugs.launchpad.net/nova/+bugs?field.tag=juno-rc-potential
14:01:29 <mjturek> o/
14:01:32 <johnthetubaguy> is the list of bugs that might trigger RC2
14:01:48 <johnthetubaguy> but its testing time I guess
14:01:54 <johnthetubaguy> anyone got any RC related things?
14:01:55 <bfic> hi guys
14:02:15 <johnthetubaguy> #topic Kilo
14:02:25 <johnthetubaguy> so juno-rc is cut, so master is now kilo
14:02:54 <johnthetubaguy> #info nova-specs are open for kilo but template changes may be on the way
14:02:58 <bauzas> when do you plan to open kilo specs ?
14:03:02 <bauzas> oh
14:03:17 <johnthetubaguy> #info master is open for kilo
14:03:23 <dansmith> jogo had some patches up for templates
14:03:31 <dansmith> if they're not in, we should make short work of them
14:03:47 <dansmith> https://review.openstack.org/#/c/125153
14:03:49 <dansmith> is the bottom one
14:04:03 <johnthetubaguy> #info please reach out to the people who have −2s on your patches if the need to be removed, once blueprints are re-approved for kilo, etc
14:04:15 <johnthetubaguy> dansmith: good point, I meant to hunt those out
14:04:36 <dansmith> johnthetubaguy: oh, speaking of un--2ing patches and blueprints
14:04:58 <dansmith> a few of us were discussing whether we need a spec for general objects work this time, or just a blueprint to "keep doing what we've been doing"
14:05:15 <dansmith> and it seemed like the consensus was that a spec is rather meaningless (the one for juno definitely was)
14:05:19 <belliott> less specs is better
14:05:29 <dansmith> are you cool with that? we talked about not always requiring specs this time for obvious stuff
14:05:30 <johnthetubaguy> dansmith: good question, does the blueprint help your tracking? I am good just ignoring the need for a blueprint
14:05:38 <johnthetubaguy> ah, cool, so yes
14:05:53 <dansmith> I think a blueprint helps tie together things that are ranom object conversions and such yeah
14:06:00 <danpb> dansmith: i think everyone understands what the objects work is about so a spec doesn't add any value there
14:06:03 <johnthetubaguy> #info new blueprint policy means the same things need a blueprint, but they don't all need a spec
14:06:10 <danpb> so i'm fine with ignoring specs for that
14:06:31 <johnthetubaguy> #link http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#when-is-a-blueprint-needed
14:06:41 <mriedem> +1 for objects bp for tracking
14:06:42 <dansmith> okay, I'll file a blueprint then
14:07:06 <johnthetubaguy> dansmith: cool, drop me a link, and I will approve it for you
14:07:12 <dansmith> okay
14:07:28 <johnthetubaguy> I don't really mind not having a blueprint either, since its refactoring really
14:07:38 <johnthetubaguy> but tracking can help
14:07:53 <dansmith> a blueprint helps,
14:07:59 <dansmith> even if it's just so we have a common topic in gerrit
14:08:07 <johnthetubaguy> yeah, true
14:08:14 <johnthetubaguy> helps find the reviews
14:08:17 <johnthetubaguy> cools
14:08:21 <johnthetubaguy> one more thing...
14:08:44 <johnthetubaguy> stuff that had code approved, but didn't make juno
14:08:52 <johnthetubaguy> we should try get that merged ASAP
14:09:07 <johnthetubaguy> so I will try help people through with the paperwork
14:09:14 <mriedem> code approved?
14:09:22 <mriedem> bp approved?
14:09:29 <johnthetubaguy> well, first code approved
14:09:34 <johnthetubaguy> theres a few of those
14:09:35 <mriedem> e.g. the tags stuff
14:09:43 <mriedem> the code wasn't approved,
14:09:52 <mriedem> it's my understanding that has to go through spec review again?
14:09:59 <mriedem> and be put into a project priority theme?
14:10:00 <johnthetubaguy> yeah, just missed freeze too
14:10:08 <johnthetubaguy> OK, we are getting ahead
14:10:19 <mriedem> sorry, an example would help if there is one
14:10:21 <johnthetubaguy> so the stuff that just missed juno-3, etc
14:10:32 <johnthetubaguy> hmm, no garyk, I think he had one
14:10:37 <mriedem> so not bps
14:10:44 <johnthetubaguy> it was a blueprint
14:10:48 <johnthetubaguy> code was approved
14:10:57 <johnthetubaguy> but got pulled
14:11:01 <johnthetubaguy> as gate was jammed
14:11:06 <johnthetubaguy> lets fast track that in,
14:11:19 <mriedem> don't we need a 2 week policy discussion on that first :)
14:11:23 <johnthetubaguy> I was going for any nova-driver approving those specs themselves
14:11:30 <johnthetubaguy> mriedem: screw that
14:11:43 <johnthetubaguy> so the next one
14:11:54 <danpb> when re-submitting specs for Kilo, should we leave the existing spec in nova-specs.git for juno, or do a git mv  into the kilo directory  ?
14:12:01 <dansmith> #link https://blueprints.launchpad.net/nova/+spec/kilo-objects
14:12:13 <mriedem> danpb: i assumed it moved to kilo
14:12:16 <johnthetubaguy> danpb: it should be left behind I think, mikal has a review that makes that clearer
14:12:21 <mriedem> oh
14:12:29 <johnthetubaguy> mriedem: yeah, I was hoping for a mv, its easier to review
14:12:31 <danpb> mriedem: exactly why i asked :-)
14:12:41 <johnthetubaguy> the ML had a thread on this
14:13:08 <dansmith> but, template changes?
14:13:18 <mriedem> right
14:13:21 <mriedem> we have project priorities now
14:13:35 <johnthetubaguy> dansmith: yeah, has to pass the tests, we might alter ones that get merged before we change the template
14:13:44 <dansmith> johnthetubaguy: ah, right, cool
14:14:06 <johnthetubaguy> dansmith: I am thinking we just wedge in the stuff that has code waiting that allready review, and mostly there
14:14:17 <johnthetubaguy> then tidy up what we have to
14:14:29 <johnthetubaguy> so in the ML we were talking about a git commit tag "Previously-approved: Juno"
14:14:41 <dansmith> makes sense
14:14:42 <johnthetubaguy> and a link to the juno spec in the new spec
14:14:48 <johnthetubaguy> keep it simple
14:14:59 <johnthetubaguy> does that work for people?
14:15:08 <garyk> works for me
14:15:39 <mriedem> johnthetubaguy: is that going into the template?
14:15:47 <mriedem> johnthetubaguy: or is that part of mikal's patch you mentioned?
14:15:48 <garyk> just the following does not make sense: link to the juno spec in the new spec
14:16:01 <garyk> what is the new spec?
14:16:10 <johnthetubaguy> #info add this to the commit message for any kilo spec submissions where the spec was approved during juno: "Previously-approved: Juno"
14:16:13 <mriedem> garyk: i'm assuming link to the juno spec review from the kilo spec
14:16:15 <mriedem> or whatevs
14:16:20 <johnthetubaguy> mriedem: git commit, then link inside the spec
14:16:28 <johnthetubaguy> mriedem: I think thats easiest?
14:16:30 <garyk> mriedem: ok, thanks
14:16:51 <johnthetubaguy> mriedem: sorry, yeah
14:16:53 <mriedem> i guess we'll get slapped when we eff up so that's fine
14:17:05 <johnthetubaguy> sure
14:17:15 <johnthetubaguy> we are just making it up as we go along right now
14:17:26 <johnthetubaguy> so do something sensible, so we spot it, is the key
14:17:44 <johnthetubaguy> my plan is to try and triage open reviews, so we get some priorities on the spec review queue
14:17:54 <johnthetubaguy> in the hope stuff doesn't get lost of weeks in there
14:18:31 <johnthetubaguy> any confusion, just ping a nova-driver in IRC, and hope we can try and help
14:18:38 <johnthetubaguy> anyways, does that all make sense?
14:18:43 <johnthetubaguy> less things need a spec
14:18:52 <johnthetubaguy> previously approved specs need a rubber stamp
14:19:08 <johnthetubaguy> if code was already approved, add a node in the review comments
14:19:23 <johnthetubaguy> in the later case, single nova-driver can approve?
14:19:32 <johnthetubaguy> (i.e. I will try push those along)
14:20:05 <johnthetubaguy> so the bike has nice shed, with a view of the coast
14:20:10 <dansmith> heh
14:20:13 <johnthetubaguy> #topic Gate status
14:20:20 <johnthetubaguy> hows we doing
14:20:30 <johnthetubaguy> interesting thread on stable branches being screwed
14:20:37 <garyk> MS for vmware is broken
14:20:38 <johnthetubaguy> but hows master
14:20:38 <dansmith> I think we landed a bunch of nova fixes for the gate last week
14:20:49 <mriedem> one bad one was reverted last night
14:20:57 <mriedem> and a couple other top gate bugs were skipped
14:20:59 <dansmith> mriedem: which?
14:21:09 <mriedem> dansmith: sdague has a big list in the dev ML this morning
14:21:15 <johnthetubaguy> hmm
14:21:18 <mriedem> with blame all around :L)
14:21:28 <dansmith> sdague has lots of large ML threads.. hint?
14:21:34 <dansmith> subject line?
14:21:41 <mriedem> #link http://lists.openstack.org/pipermail/openstack-dev/2014-October/047639.html
14:21:57 <dansmith> oh, that was yesterday
14:22:04 <mriedem> Bug 1375108 - Failed to reboot instance successfully with EC2 is reverted
14:22:05 <uvirtbot> Launchpad bug 1375108 in nova "Failed to reboot instance successfully with EC2 " [High,Confirmed] https://launchpad.net/bugs/1375108
14:22:11 <mriedem> Bug 1323658 - Nova resize/restart results in guest ending up in inconsistent state with Neutron is skipped
14:22:13 <uvirtbot> Launchpad bug 1323658 in nova "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Critical,Confirmed] https://launchpad.net/bugs/1323658
14:22:20 <mriedem> Bug 1374175 - test_server_cfn_init failed in gate-tempest-dsvm-neutron-heat-slow: AssertionError: Timed out waiting for 10.1.0.4 to become reachable is skipped
14:22:20 <uvirtbot> Launchpad bug 1374175 in tempest "test_server_cfn_init failed in gate-tempest-dsvm-neutron-heat-slow: AssertionError: Timed out waiting for 10.1.0.4 to become reachable" [Undecided,New] https://launchpad.net/bugs/1374175
14:22:24 <garyk> mriedem: is that icdehouse or juno?
14:22:36 <mriedem> garyk everything
14:22:40 <mriedem> that leaves Bug 1357055 - Race to delete shared subnet in Tempest neutron full jobs as top dog
14:22:42 <uvirtbot> Launchpad bug 1357055 in nova "Race to delete shared subnet in Tempest neutron full jobs" [Critical,Fix released] https://launchpad.net/bugs/1357055
14:22:46 <garyk> ok, thanks, it was not clear from the subject
14:22:49 <mriedem> dansmith: ^ we thought that was fixed
14:23:17 <johnthetubaguy> wow, OK
14:23:30 <johnthetubaguy> so help required, basically
14:23:33 <mriedem> basically sdague is mad as hell and he's not going to take it anymore :)
14:23:37 <mriedem> yeah it's the same old story
14:23:45 <johnthetubaguy> OK, that could wind him up
14:23:56 <mriedem> so neutron peeps helping out on Bug 1357055 would be nice
14:24:01 <uvirtbot> Launchpad bug 1357055 in nova "Race to delete shared subnet in Tempest neutron full jobs" [Critical,Fix released] https://launchpad.net/bugs/1357055
14:24:07 <johnthetubaguy> is it just me, or do we need to re-think the nova and neutron integration
14:24:28 <mriedem> oh god, you want to side rail the meeting?
14:24:29 <dansmith> johnthetubaguy: meaning?
14:24:43 <mriedem> we need to work on the neutronv2 api cleanup in kilo
14:24:47 <mriedem> as a project priority
14:24:52 <mriedem> beagles is on the case
14:24:53 <dansmith> mriedem: +3
14:24:58 <garyk> mriedem: agree 100%
14:25:14 <johnthetubaguy> dansmith: I guess I mean neutronv2 api "cleanup"
14:25:17 <garyk> but refactoring it is not the way to go
14:25:18 <dansmith> okay
14:25:28 <mriedem> garyk: let's not start in the meeting please
14:25:35 <garyk> that is keeping the same code flow where an instance create has 16 neutron calls is worng!
14:25:43 <johnthetubaguy> dansmith: feels like we need something less racy, like I remember us talking about in salt lake city
14:25:57 <johnthetubaguy> mriedem: right
14:26:04 <mriedem> yeah so we want bulk requests to neutron
14:26:06 <dansmith> johnthetubaguy: yes, part of the problem is that it was designed to behave like nova-network, but can't
14:26:11 <mriedem> rather than the billion that we have now as garyk points out
14:26:12 <garyk> mriedem: agree 100%
14:26:13 <johnthetubaguy> dansmith: right
14:26:14 <dansmith> right
14:26:24 <dansmith> I think we probably need neutron api changes to make it happen as well,
14:26:37 <mriedem> i think geekinutah actually has an old bp for some bulk request stuff
14:26:39 <dansmith> so redesiging our interface without that is likely to result in similar problems
14:26:44 <johnthetubaguy> yeah, thinking a cross project session, but thats maybe a waste
14:26:45 <mriedem> yeah
14:26:47 <garyk> dansmith: correct. it would be good to prosoe them at summit and then hopefully can get that moving forwards
14:27:15 <mriedem> so if we can go into the summit with a list of 'this is what makes this really bad and we need x y z api changes in neutron', can we figure that out?
14:27:16 <garyk> johnthetubaguy: a cross project session is essentail
14:27:16 <johnthetubaguy> dansmith: I almost want neutron to give us a python lib where we can "get_configuration" that we pass to the nic driver
14:27:33 <garyk> mriedem: yes, there should be no reason why we cannot figure this out.
14:27:46 <garyk> dansmith: and aaron managed to figiure out the events stuff
14:27:47 <mriedem> i'm pretty sure markmcclain had some ideas at the nova meetup in portland
14:28:01 <johnthetubaguy> yeah, we keep talking, but we need to do something
14:28:02 <dansmith> johnthetubaguy: yeah, that'd be nice, but...
14:28:16 <dansmith> this is why we need project priorities, IMHO :)
14:28:20 <johnthetubaguy> right
14:28:28 <johnthetubaguy> I don't disagree
14:28:38 <johnthetubaguy> anyways
14:28:41 <mriedem> we also need similar things with cinder, but not as critical
14:29:05 <beagles> fwiw: I brought the subject up in the neutron meeting earlier this week... there is also an item on refactoring/rewriting this code on the neutron etherpad for kilo as well.
14:29:25 <mriedem> to summarize on the gate, it's better after last night's round of reverts and skips
14:29:37 <mriedem> classification rates are high http://status.openstack.org/elastic-recheck/data/uncategorized.html
14:29:38 <garyk> mriedem: and not to throw a spanner int he works but the same will be with the scheduler when that moves out.
14:29:53 <johnthetubaguy> OK, so we should fix that
14:30:12 <johnthetubaguy> mriedem: cool, so its clearer what to fix, which is good
14:30:19 <johnthetubaguy> I mean, lets move on
14:30:34 <bauzas> garyk: well, we're precisely working on cleaning up the interfaces for the scheduler, so even that's a fair point, there should not be so much hits to do
14:30:37 <johnthetubaguy> we should make sure there is a summit session on this "nova interactions" I will raise it after the meeting
14:30:44 <bauzas> +1
14:30:45 <johnthetubaguy> #topic Open Discussion
14:30:48 <mriedem> oh btw,
14:30:57 <mriedem> is there a list of design sessions to vote on?
14:31:18 <bauzas> mriedem: https://etherpad.openstack.org/p/kilo-nova-summit-topics
14:31:30 <mriedem> is there a list that's not an etherpad of doom?
14:31:30 <johnthetubaguy> #link https://etherpad.openstack.org/p/kilo-nova-summit-topics
14:31:39 <johnthetubaguy> not as far as I know
14:31:45 <johnthetubaguy> please comment in the etherpad for now
14:31:51 <mriedem> i'm too dizzy
14:31:54 <mriedem> the colors...
14:32:05 <johnthetubaguy> mriedem: there is a button to turn that off
14:32:06 <n0ano> maybe an official vote process on the ML would be good
14:32:25 <mriedem> well in juno there were actual pages in some tracking thing for the summit
14:32:31 <johnthetubaguy> n0ano: there was a plan from ttx on the ML
14:32:59 <n0ano> if it's older than yesterday I missed it, I'll have to go back
14:33:01 <johnthetubaguy> mikal hasn't told me his plans yet, but I suspect there will be a proposed list, that could be reviewed / voted on
14:33:04 <bauzas> at least, there is a choice to make in between what will have a 40-min format session and what will be part of the contributors meetup on the last day
14:33:17 <johnthetubaguy> n0ano: its tagged with [all] not [nova] if that helps
14:33:23 <bauzas> s/make/do (French spotted)
14:33:59 <johnthetubaguy> honestly, I think the meet up day will be deciding *what* we do in kilo
14:34:14 <johnthetubaguy> including discussing the details as required
14:34:32 <bauzas> johnthetubaguy: you mean about prioritizing reviews and blueprints ?
14:34:32 <johnthetubaguy> with spill over from the previous two days of sessions
14:34:32 <mriedem> we'll need more than 40 minutes if we don't have a rough idea of the details pre-summit
14:34:38 <bauzas> mriedem: +1
14:34:47 <mriedem> e.g. alaski's grand plan for cells :)
14:35:05 <johnthetubaguy> yeah, some things might need two slots
14:35:11 <mriedem> the meetup is nice for free-form topic discussion
14:35:19 <mriedem> the design summit is not...
14:35:25 <johnthetubaguy> true
14:35:28 <alaski> mriedem: I'll be sending out a ML post at some point, otherwise we'll get nowhere
14:35:36 <bauzas> mriedem: hence the idea of the last 3rd day for this
14:35:58 <mriedem> ok, cool
14:36:07 <mriedem> i'm not even opposed to slides for this stuff
14:36:17 <johnthetubaguy> honestly I see the last day as overflow and getting concrete lists of things to do
14:36:18 <mriedem> jaypipes loves him some slides :)
14:36:24 <johnthetubaguy> mriedem: specs are ideal
14:36:28 <mriedem> sure
14:36:33 <johnthetubaguy> we were talking about requiring a spec for sessions
14:36:35 <mriedem> but i need animation!
14:36:39 <alaski> mriedem: no slides! :)
14:36:55 <johnthetubaguy> mriedem: some sort of ascii cartoon is fine right?
14:36:58 <mriedem> alright sorry to derail
14:37:01 <johnthetubaguy> anyways
14:37:01 <dansmith> are we off the rails?
14:37:02 <dansmith> heh
14:37:08 <johnthetubaguy> lol
14:37:13 <johnthetubaguy> OK, any more for any more
14:37:27 <johnthetubaguy> summit plan coming soon, please express ideas in the etherpad
14:37:31 <mriedem> #link https://review.openstack.org/#/c/125514/
14:37:33 <mriedem> review that ^
14:37:36 <mriedem> for rc2 i guess
14:37:47 <jaypipes> mriedem: :P
14:38:02 <mriedem> oh is there a bootlegging session tomorrow?
14:38:06 <mriedem> jaypipes: dansmith: ^
14:38:10 <dansmith> mriedem: docs
14:38:16 <mriedem> ok
14:38:26 <johnthetubaguy> cool, any more for any more?
14:38:34 <dansmith> please no
14:38:37 <mriedem> yeah one sec
14:38:55 <mriedem> containers stuff - has anyone checked with those guys to see if they are on track for something to be presented at the summit?
14:39:08 <johnthetubaguy> I haven't, I will email them
14:39:08 <mriedem> they seem to go into hiding for months at a time
14:39:18 <dansmith> they're in their containers
14:39:22 <mriedem> hi-o
14:39:23 <dansmith> isolation, man
14:39:25 <bauzas> mriedem: they're designing APIs AFAIK
14:39:25 <garyk> mriedem: i think that they are jaded with the removal of the driver
14:39:27 <johnthetubaguy> cheaper to ship them that way
14:39:30 <johnthetubaguy> anyways
14:39:34 <mriedem> ok, that is all
14:39:38 <johnthetubaguy> cools
14:39:40 <johnthetubaguy> thanks all
14:39:45 <johnthetubaguy> happy reviewing
14:39:45 <bauzas> mriedem: and they were asking for integration with the current scheduler
14:39:51 <johnthetubaguy> watch out for those rc bugs
14:40:03 <johnthetubaguy> #endmeeting