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