04:04:34 #startmeeting masakari 04:04:35 Meeting started Tue Jul 4 04:04:34 2017 UTC and is due to finish in 60 minutes. The chair is rkmrHonjo. Information about MeetBot at http://wiki.debian.org/MeetBot. 04:04:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 04:04:40 The meeting name has been set to 'masakari' 04:05:28 #topic bugs(stack/critical) 04:06:45 #link https://review.openstack.org/#/c/468770/ 04:07:06 Reviewing for above patch is stopping. Can you review this patch? 04:08:02 This particular issue will be fixed in another patch 04:08:12 rkmrHonjo: #link https://review.openstack.org/#/c/469029/ 04:08:26 I will update it soon 04:08:31 That's the patch I'm talking about 04:09:46 Dinesh_Bhor, tpatil:Oh. Please write it on commit message. And please abandon https://review.openstack.org/#/c/468770/ . 04:10:03 Yes 04:10:43 yes 04:11:24 tpatil, Dinesh_Bhor: thanks. 04:12:57 By the way, I saw that Abhishekk sent a mail to devML for #link https://review.openstack.org/#/c/469029/ . 04:13:35 Abhishekk: Do you have a plan after that? 04:13:50 rkmrHonjo: yes, we will involve operators in that mailing thread 04:14:23 rkmrHonjo: we will try to find out how operators are handling this scenario 04:15:18 abhishekk: I see. thanks. 04:15:34 Question is: If the vm is in resized state and if the compute host on which the vm is down, then how will operator evacuate the vm 04:17:12 the main issue we would like to understand here is how the _resize instance folder created on the source compute host will be cleanup by the operator after the vm is evacuate after resetting the state in case of non-shared storage 04:17:56 our observation is the _resize instance files will remain on the source compute node and will require manual cleanup 04:18:46 tpatil: Or, should we modify init host process of nova-compute? 04:20:42 "init host process" means.... it works when nova-compute is launched. 04:21:13 rkmrHonjo: We will check if init_host will resovle this problem, but why will operator restart the nova-compute service in this situation 04:21:48 tpatil: ah...you're right. 04:22:01 and the periodic task doesn't take care of this situation 04:23:38 tpatil: ok. 04:23:59 we will involve operators in the mailing thread and see how they take care of this situation 04:24:38 accordingly, we will decide with the plan how to fix this problem 04:26:12 tpatil: I understand. I'll watch the mailing thread. 04:27:51 OK. Do you have any other items to discuss? 04:28:06 Next topic, please 04:28:37 #topic Discussion points 04:29:19 Make nova "on_shared_storage" option configurable for evacuate API 04:29:48 Presently, on_shared_storage parameter to the evacuate api is hard coded to True 04:29:57 should we make this configurable? 04:31:12 if this config option is false, then masakari shouldn't evacuate instance in resized state otherwise the _resize instance files will remain on the source compute node 04:31:20 we can add this logic in masakari 04:32:50 Do you create the option for _resize instance? or, for operator who uses non-shared-storage environment? 04:34:00 both 04:35:22 if operator has configured instance path on non-shared storage, and maskaari pass on_shared_storage parameter as True to the evacuate api (current code), then the evacuate api will fail 04:35:55 and the notification request will anyway marked as error 04:37:45 tpatil: You said that "then masakari shouldn't evacuate instance in resized state". Is this the case of non-shared storage? or both? 04:38:03 both=share storage and non-shared storage 04:38:25 for shared_storage, there is no issue 04:39:15 tpatil: OK. I agree to be it configurable. 04:40:04 Do we need lite-specs or just blueprint will do to add this config option? 04:42:03 tpatil: hm....I think that these are unnecessary if default value is "True". 04:42:08 Any other opinions? 04:42:33 no 04:42:47 s/no/nothing/ 04:44:33 We all agree to make this configurable, correct? 04:44:34 tpatil: ok, please write the patch. If anyone requests to write bp/spec on gerrit, please write it. 04:44:46 ok, got it 04:46:21 Next item from discussion point: Instance gets auto-confirmed(uses new flavor) if masakari evacuates an instance which was partially resized(resize-confirm is not performed) 04:46:21 thanks. discussion for "Make nova "on_shared_storage" option configurable for evacuate API" is closed. 04:48:01 The above item was added to let everyone know that when masakari evacuate the resized instance, it implicitly auto-confirm resize operation and use the new flavor during evacuation 04:48:40 from user's point of view, is it good or bad? 04:48:48 Is this idea means that masakari calls resize-confirm API? 04:49:04 no, it doesn't call resize_confirm API 04:49:51 what I mean is it uses new flavor during evacuation 04:50:11 tpatil: oh, I understand. 04:52:14 tpatil: I'd like to hear the opinion for it from my operator after that. 04:52:28 s/after that/after this meeting/g 04:52:38 the problem is if the user had resized instance for experimental purpose and he/she was going to revert it , then after evacuation the instance flavor cannot be downsized 04:52:53 rkmrHonjo: Sure 04:53:45 tpatil: thanks. I'll share heard opinions in next week. 04:55:52 Should we go to next item? 04:55:58 yes 04:56:17 Recovery method customization 04:56:49 we are done with identifying the changes required for adding mistral driver support 04:57:24 will modify the masakari-specs and upload it ASAP 04:57:30 abhishekk: great. 04:58:20 There is no time. Do you want to talk about db purge? 04:58:48 rkmrHonjo: we are working on implementation now 04:59:01 ok, thanks. 04:59:31 Time is over. thank you for all. 04:59:36 thank you 04:59:39 thanks 04:59:41 thanks 04:59:55 #endmeeting