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