21:02:10 #startmeeting nova 21:02:11 Meeting started Thu Oct 4 21:02:10 2012 UTC. The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:13 The meeting name has been set to 'nova' 21:02:23 * Vek yawns 21:02:34 who is here? 21:02:40 o/ 21:02:45 o/ 21:02:46 o/ 21:02:50 o/ 21:02:56 #topic Agenda 21:03:18 o/ 21:03:25 if we could start with the design summit sessions... 21:04:01 #link http://wiki.openstack.org/Meetings/Nova 21:04:04 sure 21:04:11 I was going to ask for people to help review them 21:04:12 vishy: hey! 21:04:19 can you help me in getting vnc to work ? :) 21:04:56 vishy: do you think all the topics are now covered, and you just need to review the existing proposals for inclusion ? 21:05:20 zykes-: not during the meeting no 21:05:20 in which case no need t obe too strict, you have extra room 21:05:44 vishy: I see some potential for merging... 21:05:51 #topic Summit Session Review 21:05:59 ttx I don't see anything missing yet 21:06:10 "Nova database archiving strategy" & "Improving Nova's database consistency" 21:06:19 sound like they could fit a single 40min slot 21:06:58 same for "Scheduler for HPC with OpenStack" and "HPC for OpenStack" 21:07:18 otherwise all the others made sense when I read them 21:07:40 except maybe "Network Application Rate-limiting" but you have more room fr it than Quantum has 21:07:59 the db ones aren't really related, but you might be right that they don't both need 40 min 21:08:11 the HPC ones should be combined i think 21:08:19 vishy: I was surprised in not seeing a service group submission from yun mao, is he not going to be there? 21:08:35 i'm here.. 21:08:39 :) 21:08:42 sdague: interesting yeah that should be a session 21:08:50 maoy: there you are :) 21:08:52 maoy: do you have a session for that? 21:08:58 vishy: you can do that at scheduling time, just accept them both and put a note about the future merging in the reviewers comments 21:09:04 vishy: yeah. distracted from proposing 21:09:04 (merging the two HPC sessions) 21:09:24 note: I'll remove the suggest session button at the end of the day 21:09:31 so better submit now 21:09:53 hehe 21:09:57 maoy: gogogo 21:10:07 maoy: also this seems like it is up your alley; http://summit.openstack.org/cfp/edit/3 21:10:26 http://summit.openstack.org/cfp/details/3 21:10:48 edit/3 is 403 for non topic-leads 21:10:52 sorry thx :) 21:11:19 ttx: i'll submit soon 21:11:56 vishy: looks like you have most bases covered. and a few extra sessions you can use as empty slots to facilitate scheduling 21:12:09 so if anyone else has input on the sessions I could use help 21:12:09 vishy: the other question would be on some of the API consistency discussions, which I know is a can of worms. 21:12:19 vishy: I'll talk to you tomorrow to help you with final approval/scheduling 21:12:41 sdague: we have one api consustency discussion in the process track already 21:12:43 ttx: cool 21:12:45 vishy: reading #3.. sounds like orchestration 21:12:50 ttx: ok cool 21:13:01 that's probably a better place for it then 21:13:01 sdague: oh we should have a session about that, can you propose 21:13:07 vishy: i won't be there for the entire summit though. only mon - wed. 21:13:08 maoy: exactly 21:13:21 vishy: sure, you want another one for nova beyond the process track? 21:13:24 sdague: see http://summit.openstack.org/cfp/details/53 21:13:56 vishy: we don't have any session on openstack API anymore 21:14:17 vishy: deprecation, future, integration of extensions... 21:14:33 used to have one in the Process track but has been abandoned 21:14:42 russellb: are you here? 21:15:02 vishy: redhatters are in some kind of sprint this week 21:15:30 vishy: i think #3 is probably good to cover orchestration. I'll make sure to be there and talk a lot. :) 21:16:12 maoy: great 21:16:22 ok lets move on 21:16:23 ttx: I could see that going either way. I think gabe's session is more cross project, we've got plenty of rough cases within nova. so I'm happy to either propose something if we want a more nova focussed session, or pile in on gabe's session 21:16:35 vishy: could you schedule #3 and service group (soon to be proposed) mon - wed.. 21:16:37 sdague: we should have a nova session 21:16:45 to discuss 2.1 vs 3 and timing 21:16:47 vishy: ok, I'll put something in after the meeting 21:16:50 maoy: yes 21:16:58 sdague: I thoini we can use a nova-specific session 21:17:03 think* 21:17:05 vishy: thx 21:17:29 #topic DB migration bug 21:17:30 sdague: gabe's session will be crowded and more orietned twoards consistency 21:17:41 #link https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1061166 21:17:42 Launchpad bug 1061166 in nova "ec2 instance IDs are broken after folsom upgrade" [High,New] 21:17:44 ttx: agreed 21:17:47 * ttx disappears 21:17:57 so this is a pretty nasty bug and the real fix requires a db migration 21:18:11 but we don't have a good way to backport db migrations 21:18:22 dan prince has a session about it 21:18:30 vishy: I think the fix-in-code is better here 21:18:39 so the issue seems to be that the migration does not set deleted=0 21:19:02 so as a workaround we are thinking just remove the deleted=0 check when returning values in the db layer 21:19:17 my thought is a) remove the check (backport this one) 21:19:33 just submited this oneliner to fix that: https://review.openstack.org/#/c/14063/ 21:19:34 b) add a migration to fix the NULLs (don't backport this one) 21:20:00 c) remove the workaround 21:20:05 adam_g: that makes sense to me 21:20:32 I guess we can discuss on the review. When I added it to the agenda, I thought we were going to actually have to do a db migration 21:21:07 im not certain those unpopulated columns are really even necessary, but if they are (or will be) they should probably be populated via a new migration 21:22:44 adam_g: i guess there is a small issue of having duplicates right? 21:23:03 if you were running folsom without the patch it would create a second copy of the migration 21:23:10 * of the mapping 21:24:10 i think if you're already running folsom, the mapping is already broken and you've probably worked around it on your own 21:24:24 adam_g: ok 21:24:29 #topic Bare Metal Discussion 21:24:42 so I don't know if we have enough core members here to discuss this 21:25:05 but we promised the bm folks that we would be quick to review when they reproposed 21:25:12 Well, I'll just say I've been skipping those patches, largely because of the size and my unfamiliarity... 21:25:28 and there are things to discuss. I was hoping to discuss it before the summit but maybe it will have to wait 21:26:11 vishy: I think it would be helpful to wait for the summit session, as I think there is a lot to digest there 21:26:19 so it appears that there is only one change needed to the db to support one nova-compute supporting multiple nodes/hypervisors 21:26:28 which is to add a column to the instances table 21:26:47 the main question that needs to be determined is what to do about the bare metal database 21:26:59 sdague: +1 21:27:08 well i guess the best plan is just for people to familiarize themselves with the code in advance of the summit then 21:27:28 mainly we need to make a decision about how integrated the bare metal stuff should be with nova 21:27:30 vishy: agreed, I'll carve out a piece of tomorrow afternoon to dive through them personally 21:28:08 this includes the db and the new binaries, whether it should be done with a new api extension, new database, new binaries, using host aggregates, etc. 21:28:20 sdague: great 21:28:37 hopefully we can make some concrete decisions at the summit 21:32:01 #action nova-core to review bare metal code for decisions at the summit 21:32:09 #topic Open Discussion 21:32:42 are we going to reinstate review days at some point? Also, we need more people to keep an eye on novaclient reviews 21:32:43 anyone have anything? 21:33:00 question on nova-manage, and what we should be doing with that going forward 21:33:16 going forward we should get rid of it 21:33:22 I am correct in understanding everything except the db-sync import/export should go away? 21:33:25 ok :) 21:33:29 NoVNC question. exactly what is this package supposed to provide? it no longer starts a service, as thats handled by nova-novncproxy now. is this correct? 21:33:31 vishy: any comments on the database soft-delete conversation? 21:33:32 i was actually considering working on a hack project to remove the db-sync as well 21:33:47 adam_g: it provides the html 21:33:49 i think 21:34:07 jog0: i'm for removing it if we have good workarounds 21:34:44 having a proper audit infrastructure would also be nice on that... 21:34:44 jog0: simple_tenant_usage will break for example 21:34:49 vishy: ok, good. we'll start proposing patches to make it go away. chris yeoh on our team who knows michael still pretty well was going to tackle that. 21:34:53 vishy: can we assume nova doesn't have to directly take care of keeping record around? 21:35:16 jog0: "keeping record" ? 21:35:21 Q: are we going to reinstate review days at some point? 21:35:42 Vek: wasn't planning on it. Do you think we need it? 21:35:57 Also, we need more people to keep an eye on novaclient reviews; seems like right now these are being handled by vish, jk0, and myself alone... 21:36:21 vishy: I was just wondering. I found it helpful to ensure I did a review day frequently enough to stay core :) 21:36:45 Vek: oh, yeh, I always miss the clients. I'll start trying to remember to look :) 21:36:45 and not being scheduled for a review day is why Dragon was dropped from core. 21:37:06 vishy: yeah, can it rely on shadow tables or notifications/celimeter? 21:37:48 vishy: can we rely on ^ for long term record keeping* 21:37:55 jog0: sure 21:38:17 one more note on the soft-deletes issue; I remember someone having a problem due to a flavor that had been hard-deleted from the database--they couldn't get information for making the correct charges for an instance on an old flavor. 21:38:22 Vek: I see. 21:38:37 Vek: that is another thing that needs to be worked around 21:38:46 *nod* 21:38:46 data from flavors needs to be copied into the instances table 21:40:11 vishy: right 21:40:37 but if we have good solutions for the workaround I'm ok with removing the soft-delete stuff 21:40:46 * for the issues 21:41:09 vishy: great 21:41:30 and let me just say that having the devstack tests fail so frequently is starting to get somewhat annoying... 21:41:36 Vek: I don't really see the need to add review days back honestly. If people aren't self-motivated to review, then they don't need +2 rights. If someone can't remember, they can set their own review day. 21:41:52 Vek: I agree on devstack gate, we shoud spend some time trying to fix that 21:42:10 OK, good to know (re review days) 21:43:47 cool i think we are done 21:45:16 #endmeeting