04:00:29 <takashi> #startmeeting masakari
04:00:30 <openstack> Meeting started Tue Jan 10 04:00:29 2017 UTC and is due to finish in 60 minutes.  The chair is takashi. Information about MeetBot at http://wiki.debian.org/MeetBot.
04:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:00:33 <openstack> The meeting name has been set to 'masakari'
04:00:43 <takashi> hi
04:00:48 <abhishekk> o/
04:00:49 <Dinesh_Bhor> Hi
04:00:52 <rkmrHonjo> hi
04:00:56 <tpatil> Hi
04:01:21 <takashi> As samP is not available, so I'll host the meeting today.
04:01:46 <takashi> Can we proceed based on the agenda? https://wiki.openstack.org/wiki/Meetings/Masakari
04:02:46 <rkmrHonjo> Sure.
04:03:22 <takashi> #topic bugs
04:04:02 <takashi> currently there are no critical bugs
04:04:30 <tpatil> Right
04:04:51 <takashi> tpatil: Do you need some dicsussions about https://review.openstack.org/#/c/397064/ ?
04:05:07 <rkmrHonjo> tpatil: Takahara replied to your comment in this gerrit page. Please check Takahara's comment.
04:05:24 <takashi> sagara: hi
04:05:28 <tpatil> Abhishek is working on that bugs from our side
04:05:33 <sagara> hi
04:05:39 <tpatil> Abhishek, do you want to talk about it?
04:05:43 <abhishekk> yes,
04:06:18 <abhishekk> I have figure out that due to while True loop, child thread is waiting forever
04:06:54 <abhishekk> https://github.com/openstack/masakari-monitors/blob/master/masakarimonitors/instancemonitor/instance.py#L165
04:07:45 <abhishekk> If i move this code in a daemon thread then when I send sigterm, sigkill and sigint signal then parent and child processes are exiting correctly
04:08:00 <abhishekk> only problem with this is that it will not exit gracefully
04:08:42 <abhishekk> IMO as it is just a monitoring service, we should not care about exiting gracefully
04:08:53 <abhishekk> please provide your opinions on the same
04:09:01 <tpatil> if there are already some requests in progress and if you send SIGTERM signal to parent process, do you want child process to wait until all requests are processed or not?
04:09:15 <tpatil> IMO, it should
04:10:03 <tpatil> I have checked Takahara's comment
04:10:15 <takashi> tpatil: I think it is better to keep on-going request. At least, if masakari-api recieves uncomplete request, it should record error
04:10:26 <rkmrHonjo> I think that exiting gracefully is needed, too.
04:10:30 <takashi> to let operators to find incomplete evacuate request
04:10:55 <takashi> s/uncomolete/incomplete/g
04:11:05 <tpatil> Abhishek is working on exiting child process gracefully
04:11:19 <tpatil> He will propose that patch sometime this week
04:11:42 <takashi> tpatil: ok
04:11:57 <takashi> rkmrHonjo: Can I ask you to have a look at that patch?
04:12:10 <takashi> once it is proposed to gerrit
04:12:27 <rkmrHonjo> tpatil: Is the patch for masakari?
04:12:42 <takashi> for masakari-monitors, right?
04:12:47 <tpatil> no, masakari-monitors
04:13:19 <tpatil> takashi: yes
04:13:27 <rkmrHonjo> tpatil: OK, I understood.
04:13:38 <takashi> rkmrHonjo: thx
04:15:14 <takashi> rkmrHonjo: there is another patch for masakari monitors https://review.openstack.org/#/c/417303/
04:16:28 <rkmrHonjo> takashi: Oh, I didn't check it yet.
04:16:32 <takashi> rkmrHonjo: I'd like to ask your review about masakari monitor/client stuffs, as you created a most of them
04:17:26 <rkmrHonjo> takashi: Sure. I review it as soon as fast.
04:17:33 <takashi> rkmrHonjo: thanks!
04:17:53 <takashi> Does anybody have discussion topics related to bug stuffs?
04:19:39 <tpatil> No
04:20:03 <rkmrHonjo> no.
04:20:16 <takashi> ok.
04:20:29 <takashi> #topic spec proposal
04:20:47 <takashi> Before moving to open discussion, I'd like to discuss about spec related things
04:21:10 <takashi> It seems that samP proposed a patch to create basic files for spec repo https://review.openstack.org/#/c/418176/
04:21:34 <takashi> samP_: Hi
04:21:42 <samP_> takashi: hi..
04:22:01 <tpatil> I will review that patch tomorrow. Abhishek, can you take a look at it today?
04:22:09 <samP_> I thought I couldn't attend..
04:22:17 <abhishekk> once it is merged, I will propose specs for implementing reserved_host recovery method and specs-lite for periodic tasks
04:23:00 <takashi> samP_: np. We are just talking about spec related works.
04:23:44 <samP_> takashi: great.. thanks
04:23:59 <takashi> samP_: Can I ask one question about your patch? https://review.openstack.org/#/c/418176/
04:24:08 <samP_> takashi: sure
04:25:12 <takashi> samP_: It seems that unit tests for spec still remains as a to-do item. Will you add it soon, or need some help for that?
04:26:11 <samP_> takashi: I will add them soon.
04:27:02 <tpatil> samP_: Are you planning to add it in the same patch or in a followup patch?
04:27:24 <samP_> takashi: Im working on it now. I have just push it without them. so, others can push sepcs
04:27:46 <samP_> takashi: It will be a separate patch
04:28:09 <tpatil> samP_: Ok
04:28:23 <takashi> OK. So let's land the basic files patch first, and add unit tests in a follow-up.
04:28:39 <takashi> will have a look :-)
04:28:47 <samP_> takashi: thanks
04:29:26 <rkmrHonjo> samP_: I'm reviewing the patch. I add point(+1 or -1) after this meeting.
04:29:52 <samP_> rkmrHonjo: thanks
04:30:38 <takashi> #topic open discussion
04:30:52 <tpatil> # link: https://blueprints.launchpad.net/masakari/+spec/ha-enabled-config-options
04:31:17 <tpatil> samP_: can you please approve this blueprint?
04:31:33 <takashi> tpatil: this is a kind of specless blueprint, right?
04:31:39 <tpatil> correct
04:31:48 <samP_> tpatil: sure
04:32:05 <tpatil> samP_: Thanks
04:32:09 <samP_> we agreed not to write spec on this.
04:32:23 <tpatil> correct
04:33:17 <takashi> and the other items which require specs, we can start submitting specs after we land the basic files patch to spec repo
04:33:26 <tpatil> as agreed in the last meeting, Abhishek will propose the required blueprints and life-specs once masakari-specs patch is merged.
04:34:02 <takashi> tpatil: I see, thanks
04:34:02 <tpatil> 1) Add periodic tasks
04:34:26 <tpatil> 2) Implement remaining recovery methods
04:35:55 <takashi> tpatil: thanks
04:37:51 <takashi> Is there any other topics for today?
04:38:16 <rkmrHonjo> no
04:38:36 <Dinesh_Bhor> no
04:39:08 <samP_> any updates from Sachin@platform9?
04:39:09 <takashi> samP: I also find some blueprints about monitor/client stuffs still in new status. Can I ask you to also check them and change their status?
04:39:33 <samP_> takashi: sure, I will do
04:40:09 <tpatil> samP_: He has shared talk proposal on google docs, I think he is interested to know more the roadmap
04:40:32 <tpatil> more about the roadmap
04:40:39 <rkmrHonjo> takashi, samP_:Sorry, I forgot to change status...
04:42:11 <samP_> tpatil: thanks, I saw your replay on email. Its nice we can do a presentation on summit with them
04:42:23 <tpatil> samP: Do you have more use cases that you want to implement in Masakari?
04:43:29 <samP_> tpatil: for huge topics, Bare metal HA, and container HA
04:44:16 <samP_> for ironic(bare metal HA) I can share some basic idea.
04:45:25 <tpatil> samP_: I would like to know more about these use cases
04:45:34 <samP_> for container HA, I still thinking about a usecases.
04:46:06 <tpatil> samP: Is it possible for you to describe these use cases in etherpad?
04:46:34 <samP_> tpatil: yes, sure. I will write them down. so, we can discuss them.
04:46:43 <tpatil> samP: Thanks
04:46:49 <tpatil> we can also implement HA for Cinder volume service similar to compute node failure?
04:47:28 <samP_> tpatil: I thought about it. but they already have inbuild solution for that. right?
04:47:39 <samP_> tpatil: about cinder HA
04:48:05 <samP_> same goes for neutron
04:48:17 <takashi> samP_: are you talking about cinder-volume act/act?
04:48:25 <samP_> takashi: yes
04:48:28 <tpatil> If that's already there, no need to worry then
04:49:00 <tpatil> I'm not sure whether all volume will be migrated automatically upon cinder volume node failure.
04:49:22 <tpatil> I will confirm about this point later
04:49:48 <rkmrHonjo> In my understanding, migrating is unnecessary if we use cinder-volume act/act.
04:49:56 <samP_> tpatil: volumes will not migrate, but other cinder-vol node will handle them insted
04:50:37 <samP_> guys.. really sorry.. I have to leave now
04:50:44 <tpatil> samP: Ok
04:51:04 <takashi> I think we already have capability for that (I mean ha for cinder service), as we can define process name or host type
04:51:12 <samP_> please put any actions items for me under samP
04:51:24 <samP_> thank you all...bye
04:51:27 <takashi> samP_: ok. thank you for your time
04:51:31 <takashi> samP: bye
04:51:39 <rkmrHonjo> samP: bye
04:52:28 <tpatil> #action: samP to review and approve ha-enabled-config-options blueprint
04:53:18 <abhishekk> sampath san has approved blueprint
04:53:40 <tpatil> Ok, great
04:54:28 <takashi> will have a look about implementation patch
04:54:32 <takashi> we have about 5 minutes left
04:55:06 <takashi> do we have any other topics?
04:55:37 <tpatil> Nothing from my side for now
04:55:43 <rkmrHonjo> I don't have other topics.
04:55:48 <Dinesh_Bhor> no
04:56:13 <takashi> ok
04:56:25 <takashi> thanks for joining!
04:56:41 <takashi> #endmeeting