14:00:46 #startmeeting Nova Live Migration 14:00:47 Meeting started Tue Dec 20 14:00:46 2016 UTC and is due to finish in 60 minutes. The chair is tdurakov. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:51 The meeting name has been set to 'nova_live_migration' 14:00:53 hi folks 14:01:09 pkoniszewski: ? :) 14:01:22 o/ 14:01:33 so let's start 14:01:44 #topic CI 14:01:52 pkoniszewski: great research on grenade 14:02:10 haven't checked potential fix, you've submitter 14:02:15 s/submitted 14:02:22 do you need a help with that? 14:02:24 it does not work, no idea how to fix it yet 14:02:38 any help will be appreciated 14:02:42 I asked Sean for help as well 14:02:59 * tdurakov reviewing claim patch right now 14:03:07 will take a look after that 14:03:22 it looks like there are only 2 people 14:03:56 everyone is prepering for christmas :D 14:04:01 right 14:04:13 pkoniszewski: got another question on that patch 14:04:14 https://review.openstack.org/#/c/244489/50/nova/compute/rpcapi.py@453 14:04:22 why do we need that? 14:05:17 my understanding is that migration.dest_compute will be set there in any case 14:05:48 also, I think it's safe to https://review.openstack.org/#/c/244489/50/nova/compute/rpcapi.py@440 not default these to None 14:06:23 we upgrade controllers node first, by the moment someone decided to start l-m, all controllers will be up to date 14:06:30 pkoniszewski: thoughts^ 14:06:38 that's right, but compute might not be 14:07:08 do we care about computes? 14:07:35 we have to, as compute might be old one, therefore we need to drop migration object, but we don't want to lose it so we save it into the database 14:07:56 yes 14:08:00 but 14:08:26 migration object will contain dest_host by that moment, and that info will be saved already, no? 14:09:13 it isn't in the DB yet 14:10:06 it's saved for the first time in live_migration method in compute manager, I think 14:11:38 pkoniszewski: I wonder, could you move that save to task/live_migrate.py/find_destination 14:12:00 tdurakov: my mistake, it is firstly created in conductor manager, but the destination node property might bo None there 14:12:05 might be * 14:12:13 * tdurakov worrying about logic in rpcapi.py 14:12:31 it's kind of nit, will leave a comment 14:12:55 https://review.openstack.org/#/c/244489/50/nova/compute/rpcapi.py@440 - what about this one? 14:13:07 do you really need None for them? 14:13:08 but in find_destination we don't know whether we can pass it through RPC or not 14:13:23 pkoniszewski: do we need to care about that? 14:13:43 even if we can, what will happen if we save dest_node info? 14:14:13 we will do some redundant DB calls 14:14:35 :) possible 14:15:12 not sure whether we need to guard against None, we would need to ask Dan 14:15:27 i'd say that it's better for compatibility to have default to None 14:15:36 but can't see any normal reason 14:15:49 afair None is required when we remove smth during releases 14:16:12 but in case of adding a param, all the code is executed within a single node 14:16:19 that's right 14:16:36 I mean rpcapi.py and conductors code is running inplace 14:17:10 and there are no calls from compute node to check_destination it's only done from conductor 14:17:27 anyway, just add dansmith 14:17:53 do you have anything else to discuss? 14:18:04 not at the moment 14:18:12 this claim patch is the most important to me 14:18:40 ok, so I'll finish reviewing your claim patch first, and then will try to help with grenade 14:19:05 there will be no l-m meeting next week 14:19:12 so, have a great weekend 14:19:17 #endmeeting