14:01:53 #startmeeting nova 14:01:54 Meeting started Thu Apr 16 14:01:53 2015 UTC and is due to finish in 60 minutes. The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:57 The meeting name has been set to 'nova' 14:02:01 o/ 14:02:06 o/ 14:02:07 o/ 14:02:07 o/ 14:02:08 \o 14:02:08 * bauzas waves officiallyu 14:02:09 o/ 14:02:13 \o 14:02:24 o/ 14:02:25 o/ 14:02:38 o/ 14:02:44 #topic kilo release status 14:02:51 hello all 14:02:55 so we have RC1 out the door 14:03:05 we have master open for liberty 14:03:13 but there are some bloopers we need to fix 14:03:19 o/ 14:03:20 and RC2 is being triggered 14:03:31 but we need to look at what *really* needs to be in there 14:03:44 the current plan is to add *possible* candidates here: 14:03:50 https://bugs.launchpad.net/nova/+bugs?field.tag=kilo-rc-potential 14:04:04 o/ 14:04:09 o/ 14:04:14 I believe ttx is going to help review that list tomorrow, to see what we push into RC2 14:04:29 so if you have strong views, please do add comments to the bugs 14:04:37 johnthetubaguy: any idea *when* shipping RC2 ? 14:04:39 johnthetubaguy: so about an hour ago I discovered this - https://bugs.launchpad.net/nova/+bug/1445021 - which seems like it might need to add to that list 14:04:40 Launchpad bug 1445021 in OpenStack Compute (nova) "nova-compute does not start after upgrade from juno->kilo if there are boot from volume servers running" [Critical,New] 14:05:04 yeah 14:05:07 that one is bad 14:05:10 #info for really bad bugs you want into RC2 please tag with kilo-rc-potential https://bugs.launchpad.net/nova/+bugs?field.tag=kilo-rc-potential 14:05:26 +1 I added a tag 14:05:38 sdague: honestly, thats worth delating RC2 to get a fix in 14:05:51 johnthetubaguy: yeh, if we can figure out what the fix is 14:06:02 sdague: good point 14:06:25 I mean we can wait until monday, I believe, but will have to check 14:07:00 sdague, I think I know what the fix could be 14:07:04 bauzas: to answer your question, it happens sometime after today, when we are happy with the list of things we have 14:07:04 would it be possible to see with logstash when it happened ? 14:07:04 let me propose something 14:07:09 ndipanov: ok 14:07:15 sdague, but let's talk after the meeting 14:07:21 cools, good stuff 14:07:22 johnthetubaguy: yeah my question was before sdague's point which is totally valuable 14:07:23 bauzas: no, this is discovered in a new test 14:07:31 ah 14:08:02 so, any more things on kilo? 14:08:11 so this code has been like that for a long time, and I am really surprised that it worked 14:08:22 but let me comment on the bug - disregard me 14:08:31 … time for more tests, tests are good 14:08:38 anyways, lets move on 14:08:49 #topic liberty release status 14:08:56 so we are open for liberty 14:09:02 its time to upload nova-specs 14:09:07 its time to review them too 14:09:20 planning a review day ? 14:09:26 ping me if there is any process confusion, and I can try answer "what do I do next?" 14:09:27 I have a spec question 14:09:28 like last cycle ? 14:09:49 bauzas: possible, I am keen for one before the summit, if thats feasible 14:09:54 +1 14:09:56 I put this in open discussion but I'll ask it here: we need to move to using the oslo.versionedobjects library this cycle.. do we need a spec for that, or is it straightforward enough for just a bp? 14:10:12 thats a good question 14:10:20 I am OK with that been spec-less 14:10:20 dansmith: sounds like the code is nearly the same right ? 14:10:35 dansmith: I think just a bp 14:10:39 dansmith: I briefly looked at it and found very few diffs 14:10:41 it's very close.. we have some changes we have to make, and more just transition code to make it seamless 14:10:44 we need to track it, so lets just have a bp 14:10:48 okay 14:10:51 I'm not sure there is anything that really needs discussing 14:10:59 sdague: +1 14:11:00 cool 14:11:16 so on specs, 14:11:23 previously-approved: kilo 14:11:36 is a really handy git commit tag to fast approve from kilo -> liberty 14:11:58 so other things... 14:12:07 there is likely to be a change on how we use milestones 14:12:15 https://wiki.openstack.org/wiki/Release_Cycle_Management/Liberty_Tracking 14:12:22 working with ttx on what we do there 14:12:31 https://review.openstack.org/#/q/project:openstack/nova-specs+is:open+message:%22previously%22,n,z 14:12:38 basically, more likely just to use milestones to tell people when it happened 14:12:53 which is kinda what happens now :) 14:13:04 i.e. punt from milestone to milestone until it's done :) 14:13:09 dansmith: yeah, :) 14:13:20 its basically adminiting defeat 14:13:27 at least we're honest :) 14:13:32 yeah 14:13:35 feels better 14:13:43 and its much less faffing about 14:13:52 cools 14:14:00 #link https://etherpad.openstack.org/p/liberty-nova-summit-ideas 14:14:08 #link https://etherpad.openstack.org/p/liberty-nova-priorities 14:14:25 so its time to start getting suggestions for summit discussion put in the etherpads 14:14:39 there are places for cross-project ones too (see ML message) 14:14:52 more on that soon I suspect 14:15:18 I would love to see nova-specs for the features people want to discuss, to try avoid usless sessions that could just be a spec discussion 14:15:24 but thats all 14:15:28 any more on process? 14:15:47 #topic Bugs 14:16:03 johnthetubaguy, I won't be at the summit this time - but I feel the last thing on the priorities list is kind of my area 14:16:07 how is the gate doing, nova wise? 14:16:31 johnthetubaguy, any ideas how I can still get some feedback on that (ML?) 14:16:36 johnthetubaguy: seems pretty solid 14:16:36 ndipanov: we will do a spec thingy again for priorities, so there should be space to comment without being at the design summit 14:16:37 sorry to go back to the previous topic 14:17:00 ok 14:17:11 ndipanov: can we punt that till open discussion, sorry moved on too quickly, but yes, ML is good too 14:17:18 anything more on bugs? 14:17:42 * mriedem joins late 14:17:54 mriedem: just in the bug section if you have anything 14:17:59 nada 14:18:04 #topic open discussion 14:18:15 oops 14:18:16 so I have a few notes on the agenda to go first... 14:18:20 I put my items under review requests 14:18:23 didn't mean to 14:18:24 * dansmith edits 14:18:36 * johnthetubaguy clicks refresh 14:18:44 so there are some review requests 14:18:44 done 14:18:50 mriedem: You might want to mention you've got the offending test from live snapshot bug passing w/ the experimental Fedora job :-) 14:18:52 hi, Improve performance of unshelve api - https://review.openstack.org/135387 14:18:58 https://review.openstack.org/160658 https://review.openstack.org/170031 https://review.openstack.org/135387 14:19:05 those folks request reviews 14:19:12 not sure any are "stuck" 14:19:24 none of these are stuck, IMHO 14:19:30 right 14:19:48 @all, since liberty is open for review, could you please give feedback on specs when you get time 14:20:12 abhishekk: please email mikal about removing his -2, if that doesn't happen quickly, but yes, we are reviewing the specs now 14:20:33 dansmith: your note about flavor stuff? 14:20:38 yeah, so, 14:20:40 one juno bug I backported - since it's a tricky backport - wanted to get attention of people who are also on nova-stable-maint https://review.openstack.org/#/c/173226/ 14:20:42 johnthetubaguy: sure thing 14:20:45 abhishekk: but realize that spec review bw is low until the release crtiical bugs get sorted 14:20:58 in kilo we moved flavor stuff from sysmeta to the instance extra blob 14:21:01 tricky as in - had to backport a bunch of code to make it work 14:21:04 sdauge: i understand 14:21:05 and we provided a command in nova-manage to push those migrations 14:21:09 sdague: thanks good point 14:21:28 the flavor compat code is complicated and we should drop it as soon as possible.. so what I want to poll for is: can we do that now? 14:21:39 and just say "to move from kilo to lemming you have to have done all those migrations first" ? 14:21:42 I vote "yes" 14:21:43 dansmith: is it simple to log a warning if you spot un-migrated flavors for a release after we drop the translation code? 14:21:50 or is that just silly 14:22:04 I vote yes! 14:22:05 but I also feel like we probably need a way to either block the first lemming db migration on a check, or something 14:22:18 FWIW, I am +1 the vote yes 14:22:22 ah, yeah, I like that 14:22:34 johnthetubaguy: not really, if we drop the compat code and they haven't migrated, then we'll fail to be able to load flavor info for the instance 14:22:37 which is, like, bad 14:22:47 so, we could do two things: 14:22:52 put in a DB migration to check the nova-manage command has been run, and then remove the compat code, sounds good 14:22:57 1. When the first lemming db migration hits, just augment it with an unrelated check 14:23:13 2. Make the first migration an empty shell that just checks and fails, but otherwise does no actual migration 14:23:13 yeh, that seems like 2 db migrations right? 14:23:26 yeh, I like #2 14:23:29 johnthetubaguy: right, that's my 2 14:23:31 cool, me too 14:23:32 a dummy check migration 14:23:38 yeah, I like that 14:23:42 sounds like the instance.uuid thing i had 14:23:43 excellent, I'll make it so 14:23:54 dansmith: we get to do a db drop after that? 14:23:55 fails if you don't run the script 14:24:06 sdague: a db drop? 14:24:15 dansmith: we might want to make it a general patten and document "stuff we do just after we open liberty" like adding those dummy db migrations? 14:24:29 johnthetubaguy: sounds like part of relnotes ? 14:24:31 johnthetubaguy: yeah, agreed, I was just about to say: we should make this a pattern/precedent 14:24:33 dansmith: oh, never mind, I was thinking we got to get rid of some tables / colums in the process as well 14:24:40 sdague: we didn't remember system_metadata right? 14:24:40 sdague: nope, this was all metadata 14:24:52 bauzas: I am thinking dev not users, but yes, that too 14:24:57 doesn't this drop a flavor reference though? 14:25:00 cool, sounds good 14:25:04 sdague: no 14:25:09 never, mind, I'll look later 14:25:21 ping me and we can discuss 14:25:23 johnthetubaguy: well, devs would face the db migration failure, so that's fine I guess :) 14:25:35 since when, devs are looking at devref ? 14:25:51 bauzas: I was thinking more general, just having a note of stuff to do at the start and end of each release 14:25:55 just a tick box 14:25:58 anyways... 14:25:59 ih 14:26:00 oh 14:26:07 johnthetubaguy: the next thing on the agenda was my question about the spec for o.vo, so we can skip that now 14:26:22 dansmith: ah, yes, cool 14:26:29 so nova-stable-maint 14:26:33 who raised that one? 14:26:43 me 14:26:44 * dansmith bets mriedem 14:26:46 oh 14:26:50 me 14:26:59 probably him 14:26:59 then 14:27:02 nova-stable-maint needs fixing i think 14:27:13 it's mostly non-cores and people that aren't actively involved in nova 14:27:24 so i get pretty frustrated about trying to get backports reviews for stable in nova 14:27:29 mriedem: yes, very good point 14:27:30 i don't like begging for reviews 14:27:38 but when the gate has problems it has to happen 14:27:42 we did talk about this before, and decided against just adding all of nova-core 14:27:55 i'm particularly interested in stable for two reasons, 14:27:56 yeah, stable takes a little more care 14:27:56 1. gate 14:27:59 because there are other rules 14:28:05 mriedem: do we need to get more folks to offer help, and remove the inactive folks? 14:28:05 2. i'm involved in stable maint internally for nova 14:28:13 I think step one is adding mriedem to this list 14:28:16 i'm offering to help here 14:28:18 if that's not obvious 14:28:19 but I think there are rules about that 14:28:26 right, put mriedem in the +2 list for sure 14:28:27 i.e. I don't know if I'm allowed to do it 14:28:43 yes, +1 to miedem being added 14:28:47 when I was added, 14:28:49 basically I think the point is that people that want to help and are nova core, should be added 14:28:53 I had a little intro from the stable people 14:28:59 is this a PTL thing or stable core thing? 14:29:07 any of us can add him, 14:29:08 I'm not sure that all of nova core add is a great idea 14:29:11 but I thought it was a stable core thing 14:29:19 it should be a stable core decision 14:29:26 since the review rules are different 14:29:29 yeah 14:29:32 so I can ping ttx when we sort out RC2 I guess 14:29:52 I will talk to adam_g and apevec today to see if we can quick-add mriedem 14:30:00 yeh, I think, honestly, it would just be good to get someone to write down the policy hoops to add folks 14:30:01 surely we can drop people on our own though, right? 14:30:04 sdague: I think you can add him as well? 14:30:04 ok, and i think we need to prune the list 14:30:10 sdague: it might be written down 14:30:21 dansmith: I am unconvinced that it is, it's been a bit fluid 14:30:31 sdague: well, I thought I saw it at one point 14:30:38 https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy 14:30:40 but it's entirely possible that it's out of date too 14:30:44 there should be things linking from that wiki 14:30:52 https://wiki.openstack.org/wiki/StableBranch#Team_organization 14:31:00 https://wiki.openstack.org/wiki/StableBranch#Project-specific_teams 14:31:02 yeah 14:31:02 https://wiki.openstack.org/wiki/StableBranch#Joining_the_Team 14:31:06 lol 14:31:19 "Those groups are managed by stable-maint-core, names are added after the suggestion of the Stable Branch CPL." 14:31:32 CPL? 14:31:34 CPL ? 14:31:42 Cross Project Liaison 14:31:45 I guess 14:31:51 who is that? 14:31:55 mriedem: what pruning would you do to the list? 14:32:04 nova is supposed to nominate folks for that 14:32:06 there are non-cores on there already, which makes it weird 14:32:09 I guess we just use the review count for now 14:32:25 as a start 14:32:25 dansmith: naming names? 14:32:32 dansmith: yeh, honestly, I'd drop 14:32:39 vishy? 14:32:41 Russell Bryant rbryant@redhat.com 14:32:41 Vish Ishaya vishvananda@gmail.com 14:32:41 garyk gkotton@vmware.com 14:32:41 p-draigbrady P@draigBrady.com 14:32:43 https://review.openstack.org/#/admin/groups/540,members 14:32:50 i'd drop vishy, russellb and pixelb probably 14:33:07 garyk and claudiub probably do the most reviews on nova stable 14:33:09 I'm not sure why claudio is there either 14:33:14 ok 14:33:18 it's weird that those two are on there 14:33:22 yeh, agreed 14:33:27 claudiub: was cross project stable before the project split 14:33:33 so was garyk 14:33:35 so they are legacy 14:33:38 right 14:33:45 mriedem: well, they can come back in via stable-maint-core 14:33:51 but seems weird for them to be in the -nova list if they should be on -core 14:33:52 if that's the right place 14:33:52 yeah, that 14:34:10 yeah idk who decided on that list 14:34:15 after the big split 14:34:22 so, I will hunt down apevec or adam_g today, and I can ask them about drops whilst about adding mriedem 14:34:27 yay for legacy with no audit trail 14:34:36 there is probably a trail in the ML 14:34:51 i don't care enough :) 14:35:19 anyway, sounds like we have an action 14:35:24 aye 14:35:35 #action dansmith to talk to adam_g and apevec about nova stable maint core 14:35:38 OK, sounds like we know who we need to talk to to get an answer 14:35:51 mriedem: dansmith: thanks for raising this 14:35:56 mriedem: not sure it works, you're not chair 14:36:12 meh 14:36:15 bauzas: sshh let him think he did something 14:36:16 irc://localhost:9011/#action dansmith to talk to adam_g and apevec about nova stable maint core 14:36:22 arg... 14:36:23 heh 14:36:28 copy/paste fail 14:36:32 #action dansmith to talk to adam_g and apevec about nova stable maint core 14:36:36 yeah, lol 14:36:40 : 14:36:41 :) 14:36:50 guess we know what port to attack johnthetubaguy's laptop at summit 14:36:55 :) 14:37:12 are we done? 14:37:17 I think almost 14:37:23 one more crazy idea 14:37:33 so stable list seems to get a bit stale 14:38:02 would giving them the task of driving the post Feature freeze bug fixing be totally crazy, like we never close master for features? 14:38:12 that could mean way too many backports, of course 14:38:26 but might give stable more "practice" and keep the group active… 14:38:55 johnthetubaguy, but criteria is different for pending release and stable for sure 14:38:58 I'm not sure I understand, but maybe that sounds like a process-affecting summit talk? 14:39:02 yeah 14:39:12 I think we are done 14:39:23 yeh, there is a whole issue about when handoff happens, but ttx needs to be in the middle of that 14:39:29 yeah 14:39:31 sdague: yeah, agreed 14:39:43 he has good intuition on this stuff 14:40:02 anyways, happy bug fixing and tagging 14:40:06 thanks all 14:40:10 #endmeeting