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