04:01:36 <samP> #startmeeting masakari
04:01:37 <openstack> Meeting started Tue Mar 28 04:01:36 2017 UTC and is due to finish in 60 minutes.  The chair is samP. Information about MeetBot at http://wiki.debian.org/MeetBot.
04:01:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:01:41 <openstack> The meeting name has been set to 'masakari'
04:01:55 <samP> sorry for long absent
04:02:17 <samP> #topic critical bugs
04:02:43 <samP> Any bugs need to discuss?
04:03:06 <rkmrHonjo> I'd like to discuss about https://bugs.launchpad.net/masakari/+bug/1670940
04:03:06 <openstack> Launchpad bug 1670940 in masakari "If failure host is the reserved host, the compute service of the failure host finally beccomes the enable status" [Undecided,In progress] - Assigned to takahara.kengo (takahara.kengo)
04:03:33 <samP> rkmrHonjo: ok..
04:04:00 <rkmrHonjo> samP:thanks.
04:04:08 <rkmrHonjo> There are two solutions for this issue.
04:04:20 <samP> rkmrHonjo: yep
04:04:23 <rkmrHonjo> No.1 Remove crushed node from reserved host list. Reserved flag of the crushed node will be still "True" after evacuating.
04:04:33 <rkmrHonjo> No.2 Change reserved flag of the crushed node to "False" before getting reserved host list. (As a result, crushed node will be not contained in reserved host list.)
04:05:00 <rkmrHonjo> Takahara and I think that No.2 is simpler than No.1. But we can agree with No.1 if it has advantage or reasons.
04:05:34 <rkmrHonjo> Do anyone have the opinion about this?
04:05:51 <samP> rkmrHonjo: in both cases on_maintenance': True?
04:05:59 <samP> right?
04:06:05 <rkmrHonjo> samP: yes.
04:06:36 <sagara> Is there any notification to operator both cases?
04:07:00 <tpatil> sagara: Notification is not implemented yet in masakari
04:07:23 <samP> sagara: tpatil is correct, we dont have it yet
04:07:28 <sagara> So can operator find that event in logs.
04:07:37 <sagara> So can operator find that event in logs?
04:08:23 <samP> sagara: he may, but we have out sufficient log for that
04:08:39 <tpatil> there are no logs to indicate on_maintenance is set to True
04:09:18 <samP> tpatil: yes, IMO we have to add that log msg
04:10:18 <tpatil> Sure, we will add logs for this purpose, as well as identify other places which needs logs
04:10:54 <samP> if we use solution 2., next time when we get the reserved host list, this host will still in the list with on-maintenance= true right?
04:11:27 <tpatil> samP: correct
04:11:35 <rkmrHonjo> samP: No. please wait for writing...
04:12:40 <tpatil> https://github.com/openstack/masakari/blob/master/masakari/engine/manager.py#L143, this is where on_maintenance is set to True
04:12:45 <rkmrHonjo> samP: In solution 2, reserved flag will be changed to "false". Because crushed host is not contained in reserved host list at next time.
04:13:09 <samP> rkmrHonjo: tpatil sorry I mean solution 1.
04:13:26 <rkmrHonjo> samP: OK.
04:13:40 <samP> rkmrHonjo: you are right, in sol 2. you will not get this host on the list any more
04:15:21 <tpatil> rkmrHonjo: Did you check my comment which I have added today?
04:16:15 <samP> so, if we can log out this issue, and set the host reserved=False, on_maintenance=True, then it will not effect further operations in masakari.
04:17:06 <samP> And operator can take care of it later, and he may re-add this node after fix reserved=True, on_maintenance=False
04:17:09 <rkmrHonjo> tpatil: Yes. In my understand, your comment is telling about solution 2. and, I don't think that overwriting "false" to "false" is not a problem.
04:17:30 <rkmrHonjo> s/I don't think/I think/gc
04:18:06 <samP> rkmrHonjo: I think tpatil's comment is about unnecessary logic when the node is not a reserved host
04:19:02 <rkmrHonjo> samP: Yes. But, is there problem if overwriting reserved flag from false to false?
04:19:10 <tpatil> I think we should not update on_maintenance and reserved for no reasons
04:19:39 <tpatil> There are no issues but I don't think that is a good thing to do either
04:21:24 <samP> rkmrHonjo: no issue with overwriting same value, but why generate unnecessary call
04:22:14 <tpatil> samP: on_maintenance and reserved properties of host is updated in a single call
04:22:37 <samP> tpatil: correct
04:23:23 <rkmrHonjo> tpatil, samP: OK, I agree with your opinion.
04:24:07 <rkmrHonjo> I'll tell this decision to Takahara.
04:24:32 <samP> rkmrHonjo: I also prefer to add comment there, about why we doing this
04:24:35 <samP> rkmrHonjo: thanks
04:25:07 <samP> I will add this to gerrit
04:25:17 <rkmrHonjo> samP: tanks.
04:25:23 <rkmrHonjo> s/tanks/thanks/g
04:25:31 <samP> rkmrHonjo: np
04:25:46 <samP> any other bugs?
04:26:08 <samP> #link https://bugs.launchpad.net/masakari/+bug/1663513
04:26:08 <openstack> Launchpad bug 1663513 in masakari "Masakari failed to rescue PAUSED instances" [High,Confirmed] - Assigned to Dinesh Bhor (dinesh-bhor)
04:26:08 <sagara> no
04:26:38 <samP> sorry, I missed this todo item..
04:27:11 <tpatil> samP: please add your suggestion and Dinesh will take it forward
04:27:48 <samP> tpatil: I will definitely do it today
04:28:09 <tpatil> samP: Thanks
04:28:21 <samP> if no other bugs, let's jump in to Discussion points
04:28:29 <samP> #topic Discussion points
04:28:40 <samP> About Pike work items:
04:28:54 <tpatil> Need your approval on BP: https://blueprints.launchpad.net/masakari/+spec/enable-openstack-proposal-bot
04:29:06 <samP> #link Pike work items https://etherpad.openstack.org/p/masakari-pike-workitems
04:30:09 <samP> tpatil: I think I did...
04:31:11 <tpatil> samP: I missed that point. I will request Dinesh to upload patches for community review
04:31:20 <samP> tpatil: sure, thank you
04:31:26 <tpatil> Next item: Add devstack plugin for masakari-monitors
04:32:16 <tpatil> I will add support in devstack to install masakari_monitors only on the node where nova-compute is configured
04:32:45 <samP> tpatil: great..
04:33:10 <rkmrHonjo> tpatil: Does it support all-in-one?
04:34:17 <samP> tpatil: May assign this task to you?
04:34:19 <tpatil> rkmrHonjo: I think it shouldn't matter, masakari-monitor should be run only on the node where nova-compute is running
04:34:58 <rkmrHonjo> tpatil: OK.
04:35:00 <tpatil> in other words ,it will be installed on all-in-one as well as multiple nodes
04:35:32 <tpatil> samP: Dinesh will work on this item
04:35:58 <samP> tpatil: sure..
04:36:29 <samP> tpatil: any other items would you like to bring up?
04:36:34 <sagara> I would like to confirm who writes spec and blueprint for each Pike items. Is it OK to write bp/spec by whom suggested each items?
04:37:07 <sagara> I am seeing https://etherpad.openstack.org/p/masakari-pike-workitems #L15-22
04:37:08 <samP> sagara: yes, lest discuss that after this..
04:37:30 <samP> sagara: I wrote what I thought there..
04:38:11 <samP> OK, if no other items from tpatil, let's go to bp/spec discussion
04:38:25 <samP> #topic BP/spec for Pike
04:38:45 <samP> #link bp/specs https://etherpad.openstack.org/p/masakari-pike-workitems #L15-22
04:39:35 <samP> I wrote some items, which I think need more clarification before go to implementation
04:40:21 <samP> you may suggest otherwise.. or add items
04:41:22 <samP> I just picked up them from priority H items. Priority M and L are not there yet..
04:41:33 <samP> I will add them soon..
04:42:03 <tpatil> Recovery method customization: What are the things that you are expecting to customize for execution of workflow for each notification type?
04:43:50 <samP> tpatil: recovery actions should be customizable
04:45:08 <samP> tpatil: IMO, those recovery actions can be selected from pre defined action in masakari.
04:46:53 <tpatil> To cater to this requirement, we need to check if taskflow has this support in place
04:47:12 <samP> tpatil: I think its better to write some sample customization scenario
04:47:13 <tpatil> This is certainly doable if we use mistral workflow
04:47:23 <samP> tpatil: sure..
04:48:40 <samP> tpatil: correct, since Mistral Integration is marked as M item, I thought its better not to address it here...
04:49:25 <tpatil> if you can list down pre-define actions and possible recovery action customization use cases, I will check if it can be supported by Taskflow
04:50:09 <samP> tpatil: sure, I will do that. then we can decide whether to use Taskflow or MIstral
04:50:19 <tpatil> samP: Thanks
04:51:34 <samP> #action samP create customization scenarios for recovery actions
04:52:26 <samP> And for Force Stonith, I will write the spec
04:54:10 <sagara> samP: thanks. please write that.
04:55:00 <samP> Could some onw write the spec for Notifying API progress? or do we need spec for this?
04:55:52 <samP> cause this feature has already implemented in other projects, might not need detailed spec
04:56:29 <tpatil> Honjo: Are you interested to work on this item? if not, I will work on it.
04:57:10 <rkmrHonjo> tpatil: I interest about it.
04:57:28 <tpatil> rkmrhonjo: sure
04:57:31 <samP> ok then, I will add rkmrHonjo for this..
04:57:52 <rkmrHonjo> samP: thanks.
04:58:07 <samP> rkmrHonjo: about split-brain, do you have any plans?
04:58:08 <sagara> samP, rkmrHonjo: Could you tell us any example of Notifying API progress. Is that like glance-client --progress?
04:59:11 <rkmrHonjo> sagara: No. It means that sending RPC message when API process is started/completed.
04:59:11 <samP> we only have, 1 mins left...
04:59:31 <sagara> rkmrHonjo: thanks. OK, I understood
04:59:54 <rkmrHonjo> samP: I don't have plan now. I should start to think about it.
04:59:55 <samP> lets, discuss on openstack-masakari
05:00:22 <samP> we are out of time..
05:00:36 <samP> let finish here and move to openstack-masakari
05:00:44 <samP> thank you all.....
05:00:49 <sagara> thank you
05:00:57 <tpatil> Thank you, Bye
05:00:57 <samP> #endmeeting