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