04:01:39 #startmeeting masakari 04:01:40 Meeting started Tue Mar 7 04:01:39 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:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 04:01:43 The meeting name has been set to 'masakari' 04:01:45 Hi all 04:01:51 Hi all 04:02:02 let's start 04:02:14 #topic bugs 04:02:22 any bugs to discuss? 04:02:50 # link: https://bugs.launchpad.net/masakari/+bug/1663513 04:02:50 Launchpad bug 1663513 in masakari "Masakari failed to rescue PAUSED instances" [High,Confirmed] - Assigned to Dinesh Bhor (dinesh-bhor) 04:03:43 tpatil: This was my action item from previous meeting. 04:03:43 Need your feedback on the proposed solution 04:03:55 samP: yes 04:04:17 tpatil: sorry for the delay.. I will put my comments today 04:04:24 samP: thanks 04:04:58 any other items? 04:05:07 no 04:05:27 ok then, if any other items, pls bring them in AOB 04:05:46 let's jump in to discussion for pike work items 04:05:55 #topic Pike work items 04:06:05 #link https://etherpad.openstack.org/p/masakari-pike-workitems 04:06:28 we have long list of items.. :) 04:07:18 we need to decide Pike priorities 04:07:46 sagara:+1 04:07:56 sagara: sure, and how we gonna do that, put your + on etherpad? 04:08:31 samP: I agree add + to each items 04:08:54 well, lets take a look, 04:09:11 1. Return request Id to caller 04:09:37 this is for add req-id to caller which is done in other projects.. 04:10:26 masakariclient will be invoked from masakari-monitors, correct? 04:10:36 yes 04:11:14 samP: Ok 04:12:22 I consider this is as a medium priority item, what do you think? 04:12:31 means, nice to have 04:12:37 samP: correct 04:12:47 samP:I agree. 04:13:02 samP: I agree, too 04:13:12 OK then let me mark as (M) for medium 04:13:28 2. Notifying API progress 04:13:38 +1 04:14:02 as host failure is a long running task, we need this support 04:14:13 I agree 04:14:25 lets make it (H) 04:15:00 3. Force Stonith 04:15:28 what is needed in masakari to support this feature? 04:15:53 This feature is for, force down host when it cannot rescue 04:16:27 I think it is important to kill host of semi-failure state 04:17:02 you mean, when masakari fails to process instance notification, then it should kill compute host, correct? 04:17:07 for an ex. some process are failing again and again, then we have to kill that host manually. With this feature, we can automate this 04:18:52 or we can use this feature to make sure that failed host is down for sure, before we evacuate. This is important when you do not use pacemaker 04:19:55 tpatil: did not get what you said 04:20:22 who will initiate force down host notification? 04:20:55 masakari-engine itself? 04:21:11 tpatil: masakari-engine 04:22:08 using what information masakari-engine can shutdown compute host forcefully? 04:22:50 IPMI? 04:23:07 tpatil: currently we dont have required info to do this. but we can use IPMI 04:24:15 However, I think this feature is related to recovery method customization 04:24:22 samP: correct, masakari-engine is not aware of IPMI info as of now 04:24:33 Who will write this spec? 04:24:59 I can write the spec for this. 04:25:23 samP: Ok 04:26:25 I am thinks priority for this as (M), because I think recovery method customization should come first 04:27:22 I would like to up this items priority to (H) 04:27:38 sagara: sure 04:27:51 marked as (H) 04:27:53 In HA, IPMI is used generally. Host could not accept any request like ssh in error state. so we need a way/tool to force power down. 04:28:02 samP: thanks 04:28:16 sagara: sure. agree 04:28:27 lets move on 04:28:37 4. Recovery method customization 04:28:57 (H) 04:29:06 we are discussing about this from last cycle.. 04:29:07 +1 04:29:38 I think we are aware of what it is.. 04:29:48 shall we make it (H)? 04:30:04 samP: agree 04:30:06 As of now, recovery action are implemented using taskflow 04:30:28 to make recovery actions configurable similar to mistral, it's going to be a huge task 04:31:37 tpatil: agree. we need to discuss how far we wants to make this configurable. Depend on the depth it might be not that huge 04:31:49 customization can be done using config options quite easily 04:32:54 tpatil: agree, that is one way to do it. 04:33:02 samP: ok, let's make this item as high priority 04:33:25 tpatil: thanks. lets discuss the details later 04:33:48 5. Masakari Act/Act 04:34:53 beside tooz, that else do we have to do to make this happen? 04:34:54 need act/act support for masakari-engine only, correct? 04:35:50 tpatil: yes, for api, we can use the same queue for act/act 04:35:51 I think masakari-api isn't need to do additional work for act/act 04:36:19 sagara: think same 04:37:06 what would it be? for me its (M) than (H) 04:38:23 samP: I +1 to (M) 04:38:32 samP: +1 for M 04:38:54 ok then, marked it as (M) 04:39:04 6. Documentation 04:39:28 IMHO, this is very important.. 04:39:30 I think this should be H. 04:39:38 +1 04:39:44 +1 04:39:44 Dinesh_Bhor: agree 04:39:55 OK then lets mark this as (H) 04:40:12 7. Ironic Instance HA 04:40:46 I would like to mark this as (L), because spec and BP for this in ironic is under discussion. 04:41:23 I dont think we can make huge progress in masakari for this in Pike 04:41:30 samP: Ok 04:41:40 No objection. 04:41:47 thanks, 04:41:50 Next, 04:42:03 8. Use openstack resource agents for monitor compute nodes 04:42:39 I will coordinate this with openstack-HA team, try to get some help from them 04:43:13 It's an alternative to masakari-monitors project, correct? 04:43:14 from my point of view, this is (M) item. 04:43:19 tpatil: correct 04:43:50 Is anyone from the community willing to take up this job 04:44:47 tpatil: I have to discuss with aspiers about this. 04:45:01 samP: Ok 04:45:26 tpatil: I think we can get some help for implement this for HA team 04:45:45 samP: that will be great :) 04:46:05 tpatil: I will try. 04:46:23 shall we mark this as (M) or (H)? 04:46:36 +1 for M 04:47:08 ok then, please say otherwise later.. 04:47:13 lets's go to next 04:47:24 9. istral Integration 04:47:27 sorry 04:47:31 9. Mistral Integration 04:47:49 It's nice to have thing, +1 for M 04:48:32 ls 04:48:32 it's large feature, but it is not essentially, so I think it (M) 04:49:23 OK then, marked it as (M) 04:49:41 10. Functional test 04:50:16 s/large feature/major feature/ 04:50:37 we definitely need this.. 04:50:45 Functional is (H) 04:51:12 Are we talking about writing functional tests in Tempest or masakari project? 04:51:33 tpatil: In my understanding, this is not tempest. 04:52:05 rkmrHonjo: OK 04:52:08 tpatil: its for masakari project.. 04:52:14 right? 04:52:30 in masakari 04:52:46 some of integration test in Masakari CI? 04:53:53 sagara: currently we run same tests in masakari CI, but in future masakari CI is for destructive testing. 04:54:32 samP: I thought that this item(Functional Test) means the tests like nova/tests/functional. Is this incorrect? 04:54:48 IMHO, these functional and unit testing will use openstack infra as other projects 04:55:01 rkmrHonjo: correct 04:55:16 samP: where can I find the code for tests written for masakari CI job? 04:56:03 tpatil: I will share them. currently rkmrHonjo is working on them 04:56:12 samP: thanks 04:56:27 #action samP share masakari CI test codes 04:56:49 we dont have much time left.. 04:57:01 so I would like to modify that 'Functional test' to 'destructive testing' 04:57:23 ah.. 04:57:52 lets leave it there as functional testing, because we need them. 04:58:01 samP: ok 04:58:05 shall we add a new item call 'destructive testing' 04:58:16 I will add it 04:58:26 thanks 04:58:36 I add it 04:59:01 OK, only 2 mins left 04:59:17 samP: Sorry, destructive test is equal to functional test? I think that these are not equal. 04:59:36 rkmrHonjo: no they are not equal 04:59:43 samP: thanks. 04:59:58 for the rest of the list, please put your +1 for each topic 05:00:26 then we can discuss the prority for those in our next meeting or in ML 05:00:44 samP: sounds good to me 05:00:53 thank you all.. .let's end this meeting and move to opentack-masakari 05:01:00 #endmeeting