14:00:57 #startmeeting nova 14:00:58 Meeting started Thu Apr 30 14:00:57 2015 UTC and is due to finish in 60 minutes. The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:01 The meeting name has been set to 'nova' 14:01:02 hi! 14:01:04 o/ 14:01:04 hi 14:01:05 o/ 14:01:05 o/ 14:01:06 o/ 14:01:08 \o 14:01:17 welcome all 14:01:21 o/ 14:01:24 #topic kilo release status 14:01:31 0/ 14:01:39 so this is the last time we talk about kilo, probably 14:01:41 O/ 14:02:01 kilo is out, RC3 has become the final release 14:02:10 #link https://wiki.openstack.org/wiki/ReleaseNotes/Kilo 14:02:15 yay 14:02:16 o/ 14:02:20 The Kilo is dead. Long live the Kilo. 14:02:28 \o/ 14:02:32 while its probably too late really, please do check the release notes for correctness 14:02:37 jaypipes: +1 :) 14:02:53 we should have had L be lb 14:02:58 as in pound 14:03:05 heh 14:03:05 anyways 14:03:23 sound you find a bug that takes your breath away 14:03:26 #link https://bugs.launchpad.net/nova/+bugs?field.tag=kilo-backport-potential 14:03:30 we have a tag for that 14:03:49 and hopefully the stable team might jump around and help you through that 14:04:04 anyways, thanks for all your hard work on kilo 14:04:15 so… 14:04:24 #topic liberty release status 14:04:27 \o/ 14:04:41 first things, summit sessions 14:05:01 we have a nova-drivers meeting and came up with a initial draft of nova summit sessions 14:05:09 #link https://etherpad.openstack.org/p/liberty-nova-summit-ideas 14:05:31 now, I guess we need a deadline for session submissions, anyone have a strong preference? 14:05:54 5/8? 14:06:07 yesterday? 14:06:13 yeh, in the past design summit closed out pretty late 14:06:26 yeah, I was thinking along those lines 14:06:35 the schedule was typically set the week before 14:06:45 so, lets say by the next nova-meeting, so May 7? 14:07:05 wfm 14:07:10 now there is little space left, but you know, we might find something interesting that needs debating 14:07:13 johnthetubaguy: the sooner we get a schedule up, the sooner we can start moving it around as needed 14:07:17 +1 it would prevent people just coming because session is nice 14:07:28 or having a buzzword in there 14:07:32 NFV! 14:07:37 dw they will find you 14:07:40 johnthetubaguy: bauzas: only the fishbowl sessions have to have a title in sched.org 14:07:41 ;p 14:07:45 jaypipes: feel free to suggest moves on the current one 14:07:58 johnthetubaguy: ? we have a current shcedule? 14:08:14 jaypipes: ssssht 14:08:15 jaypipes: I should have been clearer, end of that etherpad, its fully drafted out 14:08:21 AHHHH 14:08:26 got it. sorry, missed that. 14:08:47 #info full draft scheduler for all summit sessions can be found at the end of this etherpad: https://etherpad.openstack.org/p/liberty-nova-summit-ideas 14:08:57 dims: all the nova sessions are fishbowl ones, so... 14:09:22 bauzas: don't we have working sessions on friaday? 14:09:25 #info deadline for summit session submissions is 7th May 2015 before the next nova-meeting 14:09:33 jaypipes: it's unstructured 14:09:38 jaypipes: like last time 14:09:40 like in paris 14:09:47 so, we have an etherpad for that too... 14:09:48 dansmith: right. I think that's what dims was referring to. 14:10:02 yep 14:10:15 #info you can find the unstructured meetup ideas for Friday here: https://etherpad.openstack.org/p/liberty-nova-summit-meetup 14:10:27 I might regret making that public 14:10:32 so early 14:10:34 buy hey ho 14:10:39 but^ 14:10:44 johnthetubaguy: do you have edit rights on that spreadsheet? 14:11:09 johnthetubaguy: if so, would be nice to color the nova sessions some nice color. 14:11:13 jaypipes: I have edit delegated edits on sched directly, I can't move rooms 14:11:22 ah, so apparently thats not possible 14:11:32 you calling me an arsehole? 14:11:36 for reasons I don't quite understand 14:11:40 :P 14:11:47 nope, I wanted the colors too 14:12:11 but turns out we need them all the same color, I think ttx knows why, I forget what he told me, sorry! 14:12:28 OK, cools 14:12:33 any questions on the summit? 14:12:47 looks like we'll all be in room 301 for two days straight. bring yoru sleeping bag... 14:12:58 +1 14:13:00 so blueprints 14:13:02 https://blueprints.launchpad.net/nova/liberty 14:13:22 we are basically not fafing with milestones, so lets keep looking at the above link instead 14:13:24 #link https://blueprints.launchpad.net/nova/liberty 14:13:34 anyways, spec reviews are under way now 14:13:45 lots of stuff already approved and up for review 14:13:50 nit: https://blueprints.launchpad.net/nova/+spec/allocation-ratio-to-resource-tracker has no owner yet, so please add me to it 14:13:53 johnthetubaguy: ^ 14:13:59 johnthetubaguy: the big one for me is online-schema-changes now that jerdfelt is no longer working on nova.. 14:14:07 bauzas: will it not let me 14:14:10 johnthetubaguy: if we aren't doing milestones, what does that mean for feature freeze? 14:14:21 johnthetubaguy: that really is an important effort. I would be OK having a mirantis engineer pick up that work if cool with others. 14:14:41 mriedem: https://wiki.openstack.org/wiki/Release_Cycle_Management/Liberty_Tracking 14:14:48 jaypipes: oslo.db is mostly mirantis guys already right? 14:14:50 jaypipes: I am trying to find out about that, lets try sort that out off line, help would be welcome I think 14:15:02 mriedem: no, not really... 14:15:07 mriedem: feature freeze is the same, let me get the link 14:15:09 johnthetubaguy: sounds good. 14:15:10 bauzas: that doesn't say anything about freeze 14:15:33 https://wiki.openstack.org/wiki/Liberty_Release_Schedule 14:15:42 #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 14:15:45 yeah, thats the one 14:15:49 so the milestones 14:15:52 we still release them 14:15:57 we track what get released in them 14:15:58 johnthetubaguy: k, so what are you asking of us right now on the blueprints? anything in particular you wanted to get decided or done? 14:16:05 we don't try to predict what will be in them 14:16:14 mriedem: oh, my point was about saying that we're not tracking bps using milestones now IIUC 14:16:27 jaypipes: really, any questions with the process is where I was going with this, then we have two blueprints to review 14:16:51 so process, propose your blueprint for the "liberty" series 14:17:01 that should bring your bp up into that list 14:17:06 one blueprint I don't see on there that I was hoping to see was the "unfuck-the-neutronv2.py module" one from, IIRC, Brent Eagles. 14:17:07 if you need a spec, you need to add that 14:17:28 jaypipes: he has a bunch of specs up for that sort of thing 14:17:37 jaypipes: I will only review code for that blueprint if that's the actual name :) 14:17:38 jaypipes: there is a spec for that in review, I think I actually approved that, but its not quite a far ranging in its intitial form 14:17:41 jaypipes: we had a spec last time around that didn't get approved, IIRC 14:17:59 yeah, its happening, which is good 14:17:59 so am I just missing the blueprint? 14:18:03 the neutronclient wrapper spec was approved yesterday 14:18:04 johnthetubaguy: right, it's broken into smaller cleanups 14:18:34 jaypipes: looking 14:19:01 https://review.openstack.org/#/c/131413/ 14:19:05 http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/wrap-neutronclient.html 14:19:07 johnthetubaguy: jaypipes: ^ 14:19:09 https://review.openstack.org/#/c/131413/ 14:19:12 wrap neutronclient is easy 14:19:13 https://review.openstack.org/#/c/131413/ is not 14:19:17 https://review.openstack.org/#/c/141129/ 14:19:20 right, thats the other one 14:19:34 no blueprints for the nova-neutron-refactor... 14:19:51 jaypipes: what is that specifically? 14:20:02 I think those three are all part of that 14:20:11 so.... it seems weird that that spec basically says "the neutron client api is unusable, we'll build you another api" 14:20:15 mriedem: refactoring of the neutronv2.py module so people can understand it? 14:20:15 he has a couple of specs for refactoring as well 14:20:21 Refactor allocate_for_instance 14:20:25 jaypipes: that's https://review.openstack.org/#/c/131413/ 14:20:27 https://review.openstack.org/141129 14:20:33 Refactor of the Neutron network adapter 14:20:38 https://review.openstack.org/131413 14:20:39 https://review.openstack.org/#/c/141129/ references https://blueprints.launchpad.net/nova/+spec/nova-neutron-refactor, but it appears that that BP link doesn't actually exist. 14:20:41 * beagles arrives late - with ears burning 14:20:41 mriedem: right. there's no blueprint. 14:20:57 mriedem: I'm not saying there's no spec. I'm saying there's no blueprint :) 14:21:17 beagles: I'm very interested in your nova-neutron-refactor spec. wondering where the blueprint might be :) 14:21:18 idk 14:21:31 jaypipes: yeah, I will try match those up a little, for the merged one, just spotted that 14:21:31 this is kind of a waste of time imo 14:21:34 I usually don't create the blueprint until my spec is close :) 14:21:35 we can find the bp later 14:21:35 yeah 14:21:43 lets move on 14:21:48 whatevs. 14:21:59 mriedem: I don't see why this is a waste of time :( 14:22:00 jaypipes: agreed its important for liberty 14:22:07 there are specs 14:22:10 jaypipes, quite likely forgot to create the blueprint thing 14:22:10 the bp is process 14:22:28 -1 the spec review for a bp in lp 14:22:29 easy 14:22:39 then we can move on 14:22:41 :/ 14:22:44 beagles: I guess we are looking forward to the specs being refreshed for liberty for the other neutron refactoring bits 14:23:05 I think folks are keen to start reviewing them 14:23:07 which is cool 14:23:08 since it seems there are many BPs, can we track all of them in some unique place ? 14:23:14 johnthetubaguy, right 14:23:23 bauzas: yes, that's called Launchpad. :P 14:23:28 https://review.openstack.org/#/c/131413/ is the big hairy 14:23:30 so that needs review 14:23:33 bauzas: we track them too many places really 14:23:34 jaypipes: nah, speaking of the network stuff 14:23:49 lets do that offline 14:23:51 k 14:24:01 jaypipes: but thanks for the pointer, just discovering it :p 14:24:05 we have two bps that want to be approved without a spec 14:24:08 #link https://blueprints.launchpad.net/nova/+spec/convert-image-meta-into-nova-object 14:24:11 anyway, let's move on agreed 14:24:15 #link https://blueprints.launchpad.net/nova/+spec/network-template-routes-injection 14:24:20 firstly: 14:24:21 johnthetubaguy: no eventually 14:24:27 do the need a spec 14:24:35 not in my opinion. 14:24:39 secondly, do we like them 14:24:42 yes. 14:24:46 I like both. 14:24:51 are they ready to be approved (i mean) 14:24:56 yes, IMO 14:24:59 they seem OK at a quick glance 14:25:00 first one definitely does not need a spec 14:25:04 johnthetubaguy: https://review.openstack.org/#/c/76234 is finally pointing to an approved spec 14:25:06 any folks got issues with them? 14:25:07 so is instance-tagging BP, IMHO :) 14:25:36 but I agree with ndipanov, that's probably even not requiring a spec - or maybe a objects one 14:25:39 weren't we trying to get away from file injection for - https://blueprints.launchpad.net/nova/+spec/network-template-routes-injection ? 14:25:55 sdague: that's not file injection... 14:25:56 sdague: its using config drive not inject, AFAIK 14:26:03 oh, ok, no prob 14:26:31 anyways, if you have strong feelings please let me know 14:26:51 I will look to approve them tomorrow ish, assuming there are no big issues 14:27:01 thanks in advance for you looking 14:27:22 #help please review the two non-spec BPs ASAP if you are worried about them 14:27:31 #topic Bugs 14:27:41 mriedem: hows the gate looking? 14:27:54 i assume good 14:28:03 http://status.openstack.org/elastic-recheck/gate.html 14:28:13 http://status.openstack.org/elastic-recheck/data/uncategorized.html 14:28:16 the boot from volume test seems to be failing more often than previously 14:28:17 categorization rate is high 14:28:39 sdague: yeah, noticed that 14:28:58 i opened a bug yesterday for some flaky cinder failures, wasn't boot from volume though 14:29:11 do we have a ER for that boot from volume at all? 14:29:25 so the problem is, it's the generic ssh failure 14:29:27 we have one for the lvm lock 14:29:27 assuming it was the same reason it failed each time, which might be a rash assumption 14:29:31 oh… 14:29:36 gotcha 14:29:36 yeah, the new one is ssh generic failure so we can't really fingerprint it reliabely 14:29:41 which we dropped from the signature list, because it's unhelpful 14:29:45 yeah 14:29:52 mriedem, lvm lock was that thing in the libvirt driver? 14:29:55 melwitt found something yesterday, 14:30:02 which *could* be related to the ssh thing 14:30:07 ndipanov: no, not libvirt 14:30:08 dansmith: do tell 14:30:11 k 14:30:22 because any new breadcrumbs there would be awesome 14:30:25 ndipanov: no 14:30:25 sdague: I thought it was really likely when I first saw it, but now I think it's remote, but it's something 14:30:39 sdague: she realized we're not refreshing info cache from the result of a save() like every other object 14:30:55 and some neutron folks think that sprinkling refresh calls all over the place makes it go away 14:31:03 oh, that's interesting. Yeh, seems sensible to fix regardless. 14:31:05 which may just be the timing they're affecting, but this could be a thing 14:31:08 definitely 14:31:17 does she have a patch up yet? 14:31:25 dunno, this was late yesterday 14:31:30 ok 14:31:33 I'll look in a bit 14:31:38 dansmith: you mean https://review.openstack.org/#/c/178942/ ? 14:31:47 yes 14:31:57 any more bug related things? 14:31:57 once I get through with summit prep next week, I'll try to spend some time digging on some of these bugs 14:32:14 how is the trivial patch set list going? 14:32:20 I know its on a kilo etherpad 14:32:23 johnthetubaguy: that's an excellent question 14:32:25 but we can keeping using that for now 14:32:32 johnthetubaguy: I think we should open another one for Lib 14:32:35 I noticed it was a bit stale last time I checked 14:32:54 johnthetubaguy: tbh, I think most of us stopped updating that 14:33:00 yeah 14:33:07 burned out quick 14:33:11 the available bugs dropped to a pretty small list 14:33:15 but only because we made real progress I think 14:33:17 and dims was doing such a great job 14:33:40 dansmith: agreed, but kicking-off a new etherpad seems a good signal that this is not just stale 14:33:46 sure 14:33:47 +1 14:34:02 ++ 14:34:05 IDK if etherpad is the best format. 14:34:10 yeh, honestly, I expect everyone is going to need a breather and some recharge leading up to summit here 14:34:21 sdague: I was going to suggest, 14:34:21 call it EG nova-trivial-bugs ? 14:34:24 I liked etherpad 14:34:28 gilliard: what are you thinking instead ? 14:34:29 not doing it just yet and letting the bubble reinflate a bit 14:34:38 gilliard: because etherpad worked fine IMHO 14:34:39 so that there is another big chunk of things to attack when we do 14:34:47 because it requires critical mass I think 14:34:48 but I agree it would be good to kick off again during the friday meetup 14:34:54 #link https://etherpad.openstack.org/p/kilo-nova-priorities-tracking 14:34:56 spreadsheet eg google docs? We lost a lot of data about what bugs were fixes by that list. 14:35:03 Unless I missed where it went. 14:35:13 could we just stop using gdocs for such tiny things ? 14:35:15 -1 for doing this in a google doc 14:35:20 #link https://etherpad.openstack.org/p/liberty-nova-priorities-tracking 14:35:20 yeah 14:35:20 gilliard: dims was doing rollup counts 14:35:31 so its there should we choose to use it 14:35:37 yep 14:35:40 but giving it a rest for now makes a lot of sense 14:35:43 fair enough. 14:35:56 need to pick up after say liberty milestone 2 14:36:07 I was thinking during the friday meetup up 14:36:12 but lets talk more about it then 14:36:21 k 14:36:22 +1 14:36:30 #topic open discussion 14:36:36 so we have no agenda items here 14:36:40 so I have a thing 14:36:41 are we all done? 14:36:47 dansmith: fire away 14:36:54 This is now good with t-h: https://review.openstack.org/#/c/174480/ 14:37:01 recommend we slam in with extreme prejudice 14:37:23 done 14:37:25 dansmith: yes, that probably makes sense 14:37:28 cool 14:37:48 ++ 14:37:51 ++ 14:37:51 * mriedem wants to get out of 2 meetings at once 14:38:12 so all done? 14:38:28 thanks all, talk again soon 14:38:36 #endmeeting