04:00:25 <samP> #startmeeting masakari
04:00:26 <openstack> Meeting started Tue Mar 20 04:00:25 2018 UTC and is due to finish in 60 minutes.  The chair is samP. Information about MeetBot at http://wiki.debian.org/MeetBot.
04:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:00:29 <openstack> The meeting name has been set to 'masakari'
04:00:34 <samP> Hi all
04:00:36 <Dinesh_Bhor> Hi all
04:00:39 <rkmrHonjo> hi
04:00:55 <samP> Today's main items is discuss Rocky work items.
04:01:22 <samP> Any other items need to discuss before that?
04:01:32 <samP> Critical bugs/patches etc..?
04:01:35 <rkmrHonjo> Can I talk about a bug?
04:01:39 <samP> rkmrHonjo: sure
04:01:58 <rkmrHonjo> ok. I'd like to talk about #link https://bugs.launchpad.net/python-masakariclient/+bug/1756047
04:02:00 <openstack> Launchpad bug 1756047 in python-masakariclient "masakari command failed due to os-service-type1.2.0" [Undecided,New]
04:02:47 <rkmrHonjo> masakariclient uses os-service-type, but it doesn't work with os-service-type 1.2.0.
04:03:00 <rkmrHonjo> (In queen, the upper version is 1.1.0.)
04:03:09 <rkmrHonjo> The cause of this bug was written in Launcpad:
04:03:20 <rkmrHonjo> > In os-service-types 1.2.0, "ha" service has been added to os_service_type/data/service-types.json.
04:03:30 <rkmrHonjo> > So, if masakariclient tries add_service to openstack.connection.Connection object, then the error occurr.
04:03:39 <rkmrHonjo> > However, if masakariclient don't add_service, it can not get the correct proxy class for masakari's operation.
04:03:52 <rkmrHonjo> > Probably, the "ha" service of service-types.json is for use by masakari.
04:03:56 <Dinesh_Bhor> rkmrHonjo: I was able to reproduce this issue on my machine with "openstacksdk-0.11.3" and "os_service_types-1.2.0".
04:04:20 <rkmrHonjo> Dinesh_Bhor: thank you for reproducing.
04:04:27 <rkmrHonjo> So, I think we should do 4 steps.
04:04:33 <rkmrHonjo> 1. Add a class about masakari to openstack-sdk.
04:04:39 <rkmrHonjo> 2. Bump openstack-sdk version in global requierments.
04:04:45 <rkmrHonjo> 3. Fix masakariclient to use the new version of openstack-sdk.
04:04:53 <rkmrHonjo> 4. Merge the patches changing service-type from "ha" to "instance-ha" #link http://lists.openstack.org/pipermail/openstack-dev/2018-January/126476.html
04:05:12 <rkmrHonjo> I and Takahara succeeded to modify openstack-sdk and masakariclient in our environment.
04:05:22 <tpatil> Does you think #1 will be accepted by openstacksdk team?
04:05:31 <tpatil> s/does/Do
04:05:50 <rkmrHonjo> tpatil: I think that is no problem. Because it accept many official projects.
04:06:11 <rkmrHonjo> So we are preparing to submit the patch to openstack-sdk after that.
04:06:23 <tpatil> but in that case, we will need to move all code of sdk from masakariclient to openstacksdk, correct?
04:07:02 <tpatil> Anyone tried to test masakari using stable/queens branch?
04:07:13 <samP> I think Monty mention about (1) in some were..
04:07:30 <rkmrHonjo> tpatil: No, we shouldn't do it in stable/queens branch.
04:07:52 <rkmrHonjo> Because upper constraint version of os_service_type is 1.1.0 in stable/queens.
04:08:03 <Dinesh_Bhor> samP: yes, http://lists.openstack.org/pipermail/openstack-dev/2018-January/126421.html
04:08:19 <tpatil> rkmrHonjo: That's another question, nothing to do with this bug
04:09:05 <samP> Dinesh_Bhor: yes..this was the first mail in the thread
04:09:06 <rkmrHonjo> tpatil: Oh, sorry.
04:09:15 <Dinesh_Bhor> The question is "Is stable/queens branch of all masakari projects is working properly?"
04:10:11 <tpatil> Let's address stable/queens branch question later
04:10:25 <samP> In stable/queens. except python-masakariclient, others are OK
04:10:26 <tpatil> rkmrHonjo: Please continue
04:11:01 <rkmrHonjo> tpatil: Takahara tried to use masakariclient with #link https://review.openstack.org/#/c/553319/ . And it worked.
04:11:37 <rkmrHonjo> And, Louie Kwan said that this patch worked, too.
04:13:05 <rkmrHonjo> I'm glad if you try this patch and review it. (Ofcourse I review it.)
04:14:31 <tpatil> ok, Let's review this patch and merge it in stable/queens branch
04:15:38 <rkmrHonjo> tpatil: thanks.
04:15:48 <samP> rkmrHonjo: Thanks for the proposal. #553319 is to fix stable/queens and your proposed steps 1-5 is to fix master.
04:16:56 <rkmrHonjo> samP: ok.
04:17:09 <tpatil> rkmrHonjo: There is no other way to fix this issue other than moving the code to openstacksdk
04:17:13 <samP> rkmrHonjo: Agree to review and merge #553319 to stable/queens. Let's discuss your proposed steps to fix master separately (in ML).
04:18:06 <samP> tpatil: agree, even if we fixed it, then we will face same problem again in next release or sdk updates.
04:19:13 <tpatil> samP: I agree to move the code to openstacksdk but that's going to take lot of time. In the mean time, I was checking if there is any way to fix the problem in masakariclient
04:19:51 <samP> tpatil: agree, thanks.
04:19:56 <rkmrHonjo> tpatil: thanks.
04:20:50 <samP> Any other issues?
04:21:08 <samP> If any please bring them after next topic
04:21:19 <samP> #topic Rocky Work Items
04:21:31 <samP> #link https://etherpad.openstack.org/p/masakari-rocky-work-items
04:22:24 <tpatil> Recovery method customization
04:22:51 <samP> tpatil: go ahead
04:23:04 <samP> Any changes on plan?
04:23:10 <tpatil> Instead of supporting mistral driver to run recovery action workflow, I was thinking of adding recovery method customization support in the existing task flow driver
04:23:40 <tpatil> we will add specs to add this support in task flow driver first
04:25:06 <samP> tpatil: No objection on this. However, I would like to be this more configurable.
04:26:13 <tpatil> samP: Yes, the existing workflow for each notifications will be broken down into separate tasks and operator can configure which tasks to be included to run a particular workflow (instance/host/process notifications)
04:27:23 <tpatil> Anyone can write a new tasks in a separate library and include it in any workflow. This library should be installed on the host where masakari-engine is running
04:28:20 <samP> tpatil: Do you still need this lib, even if you only use task flow driver?
04:32:00 <samP> tpatil: I think we had this discussion in earlier, please update the spec for this. We can discuss in details on the spec.
04:32:35 <samP> (2) Develop Masakari Horizon plugin
04:32:52 <samP> tpatil: came back :)
04:33:00 <tpatil> sorry I lost my connection
04:33:04 <samP> tpatil: NP
04:33:16 <samP> my question was; Do you still need this lib, even if you only use task flow driver?
04:33:47 <tpatil> The default tasks will be part of masakari code.
04:33:59 <samP> tpatil: got it.
04:34:07 <tpatil> but if operator wants customization, then the new tasks can be written in library
04:34:18 <tpatil> for example sending SMS after disabling compute host
04:35:10 <tpatil> these new tasks will not be part of masakari code but it will reside in library which needs to be installed on masakari-engine node and then operator can configure it for host notification workflow
04:36:24 <samP> tpatil: understood.
04:36:26 <tpatil> Any questions?
04:36:32 <tpatil> samP: Ok
04:37:33 <tpatil> can we move to the next item ?
04:37:42 <samP> No questions for now. please add this details to spec, I would like to discuss more about how Operator would add this new methods.
04:37:54 <tpatil> samP: sure
04:38:10 <samP> let's move to next item
04:38:17 <samP> (2) Develop Masakari Horizon plugin
04:38:23 <niraj_singh> Unit test cases are failing because of service descriptor bug. Other than that all good.
04:38:39 <tpatil> It depends on https://bugs.launchpad.net/python-masakariclient/+bug/1756047
04:38:40 <openstack> Launchpad bug 1756047 in python-masakariclient "masakari command failed due to os-service-type1.2.0" [Undecided,New]
04:40:01 <samP> just approved the https://review.openstack.org/#/c/528647
04:40:39 <niraj_singh> samP:thanks
04:41:59 <samP> tpatil: niraj_singh: Thanks for doing this. This is heavy work. please ask if you need any help on this.
04:42:42 <niraj_singh> samP: yes sure. Thanks
04:43:03 <tpatil> samP: Most of the work has been completed by niraj_singh. Waiting for that bug to be fixed and he will push the patches for review
04:43:42 <samP> OK, that's great...sorry for the blocker.
04:44:48 <samP> (3) Intrusive Instance Monitoring through QEMU Guest Agent
04:44:59 <samP> Thanks for the review.
04:46:20 <samP> Louie and Greg are working on this. Let's review the spec and code and support them to merge this feature in early Rocky.
04:46:42 <Dinesh_Bhor> yes
04:47:18 <samP> Congratulations!! they got it on Lightning talk at Vancouver
04:47:33 <Dinesh_Bhor> Great!!!
04:48:01 <rkmrHonjo> cheers
04:48:07 <tpatil> That's amazing!!
04:48:10 <samP> Its better we can finish this before Summit.. and it will be great support to them.
04:48:29 <samP> (4) Add database purge support
04:48:55 <tpatil> Needs code review
04:49:24 <samP> tpatil: I will look into this. Sorry for the delay.
04:49:45 <tpatil> samP: Thanks
04:50:29 <samP> All members: please review this patch..
04:50:42 <samP> #link https://review.openstack.org/#/c/487430/
04:51:08 <samP> New Items
04:51:22 <samP> #topic New Items for Rocky
04:51:33 <samP> Sorry only have, 8 mins.
04:51:59 <samP> if we run out of time, will carry over to next week IRC meeting.
04:52:13 <samP> (1) Update notification state API
04:52:41 <samP> Who will proceed this item?
04:52:49 <rkmrHonjo> I wrote it.
04:52:59 <samP> rkmrHonjo: ok, Thanks.
04:53:38 <samP> how far we done on this?
04:54:03 <rkmrHonjo> Sorry, "how far"?
04:54:18 <rkmrHonjo> Ah, time span?
04:54:25 <samP> rkmrHonjo: sorry, this is a new item
04:54:28 <samP> ;9
04:55:10 <samP> this is some thing like force change the state?
04:55:19 <rkmrHonjo> samP: yes.
04:55:53 <rkmrHonjo> If operator recovers host manually while masakari-engine is crashed, I want to force disable notification.
04:56:07 <samP> OK, we need new API for this, and I would like to have spc for this.
04:56:39 <samP> is it possible to write a spec for this?
04:56:51 <rkmrHonjo> samP: Yes. I start to write the spec.
04:57:09 <samP> rkmrHonjo: great.
04:57:13 <samP> rkmrHonjo: thanks
04:57:40 <samP> (2) Move some code from masakariclient to openstack-sdk
04:57:53 <samP> rkmrHonjo: I guess this also you.
04:58:02 <rkmrHonjo> samP: thanks.
04:58:09 <samP> And we discussed part of this above.
04:58:51 <samP> We are running out of time. Let's discuss other items in next meeting.
04:59:08 <tpatil> samP: Ok, one quick question
04:59:15 <samP> If you have any questions or comment on discussed items, please send them to ML
04:59:22 <samP> tpatil: yes?
04:59:31 <tpatil> the openstack sensible plugin blueprint should be created in openstack-ansible project and not masakari, correct?
04:59:42 <tpatil> s/sensible/ansible
04:59:47 <samP> tpatil: In Openstack ansible project
04:59:57 <tpatil> samP: Ok, thanks
05:00:03 <samP> #endmeeting