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