04:01:22 <samP> #startmeeting masakari
04:01:23 <openstack> Meeting started Tue Feb  7 04:01:22 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:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:01:27 <openstack> The meeting name has been set to 'masakari'
04:01:44 <samP> #topic Bugs
04:01:52 <samP> Any Bug to discuss?
04:01:58 <rkmrHonjo> yeah.
04:02:02 <abhishekk> yes
04:02:18 <samP> OK, rkmrHonjo pls go first
04:02:26 <rkmrHonjo> thanks.
04:02:51 <rkmrHonjo> Return user-friendly error message when monkey_patch enabled https://review.openstack.org/#/c/426648/
04:02:51 <rkmrHonjo> , Switch to oslo_log https://review.openstack.org/#/c/421172/
04:03:13 <rkmrHonjo> I and Takahara commented to above patches, but there were no replies.
04:03:22 <rkmrHonjo> If author or co-developper of these patch are joining this meeting, please check  and reply our comments.
04:04:06 <abhishekk> rkmrHonjo: we are working on adding hacking checks, will push a patch soon
04:04:29 <rkmrHonjo> ahhishekk: OK, thanks.
04:04:47 <samP> abhishekk: thanks..
04:04:54 <abhishekk> no issues
04:05:16 <abhishekk> jenkins is failing on masakai, please refer http://logs.openstack.org/38/407538/5/check/gate-masakari-python27-ubuntu-xenial/f4435c2/console.html
04:05:42 <abhishekk> this is because maskari is not synced with upper-constraints of openstack/requirements
04:06:44 <abhishekk> test is failing as invalid version of jsonchema library (2.6.0) is getting installed
04:06:49 <takashi> abhishekk: you mean we need something like https://github.com/openstack/nova/blob/master/tox.ini#L13, right?
04:06:59 <takashi> to set upper constraints
04:07:15 <abhishekk> yes
04:07:42 <samP> that would be nice
04:08:47 <abhishekk> samP, takashi, I will create a patch, test this and then push it for review ASAP
04:09:17 <takashi> abhishekk: sure. I don't like to keep this blocker for long time... :-(
04:09:31 <abhishekk> takashi san: yes
04:09:45 <takashi> will keep my eyes on gerrit :-)
04:09:49 <samP> I found another issue with oslo.log, in current req is oslo.config>=3.10.0 for masakari. minimum version should be oslo.config==3.12.0
04:10:00 <samP> sorry oslo.config
04:10:15 <samP> abhishekk: thanks..
04:11:07 <samP> The reason is URIOpt is introduced in oslo.config==3.12.0
04:11:09 <abhishekk> takashi san, sure
04:11:16 <takashi> samP: As far as I seen in global requreiemts, it should be 3.11.0 https://github.com/openstack/requirements/blob/master/global-requirements.txt#L126
04:11:21 <takashi> s/seen/see/g
04:12:59 <rkmrHonjo> samP: oslo.config is the target of your opinion, don't you? It should be >=3.14.0, !=3.18.0 https://github.com/openstack/requirements/blob/master/global-requirements.txt#L121
04:13:08 <tpatil> samP: we should enable OpenStack proposal bot to sync it with global requirements.txt
04:13:18 <samP> takashi: thanks, I think masakari need oslo.config>=3.12.0, but global req is 3.11.0
04:13:50 <takashi> samP: ok
04:13:56 <takashi> tpatil: +1
04:14:09 <tpatil> to resolve this issue permanently. for the time being, let's sync it manually as per global requirements
04:14:18 <samP> takashi: +1 and thanks
04:15:40 <takashi> tpatil: +1, we need to sync global requirements before we release our Ocata version. IMO it would be great if we can set up proposal bot in the beggining of next cycle.
04:15:41 <samP> Ok, then, lets move to next bug, abhishekk ?
04:16:05 <abhishekk> samP: Ihave talked about jenkins failure just above
04:16:09 <samP> takashi: agree.
04:16:14 <abhishekk> s/Ihave/I have/
04:16:26 <samP> abhishekk: great..ok then
04:16:36 <abhishekk> samP: jsut reported it, https://bugs.launchpad.net/masakari/+bug/1662408
04:16:36 <openstack> Launchpad bug 1662408 in masakari "Masakari is not synced with upper-contraints of global requirements" [Undecided,New]
04:17:18 <samP> abhishekk: thanks
04:17:49 <takashi> samP: Can I ask you to confirm the bug?
04:17:56 <samP> Any other bugs?
04:18:08 <takashi> I mean, change its status to 'confirmed'
04:18:42 <samP> takashi: I think I just did
04:18:52 <takashi> samP: thanks!
04:19:03 <takashi> nothing else from my side
04:19:05 <samP> takashi: np
04:19:26 <samP> OK then, lest move to Discussion Points
04:19:41 <samP> #topic Discussion
04:20:33 <samP> I raised one issue about, deprecating bash scripts of host and process monitors
04:20:46 <samP> #link https://review.openstack.org/#/c/427584/
04:21:25 <samP> since we have new python monitors, we will not need these bash script monitors,
04:22:00 <samP> However, some ppl are still using these for testing and evaluate masakari,
04:23:07 <samP> Therefore, my proposal is lets leave them as it is for Ocata and deprecate/remove them in Pike
04:23:54 <rkmrHonjo> samP: I don't have any objections.
04:24:17 <samP> we can add this message in each bash script, so users will know this.
04:25:53 <rkmrHonjo> samP: Agree. I'll implement it.
04:26:10 <samP> if no objections, lets add message to each bash script and leave them as it is for Ocata release as deprecate candidates.
04:26:20 <samP> rkmrHonjo: OK then
04:26:47 <samP> #action rkmrHonjo  add message to each bash monitor scripts and leave them as it is for Ocata release as deprecate candidates.
04:27:10 <samP> #topic AOB
04:27:29 <samP> any other topics to discuss?
04:27:45 <tpatil> Implement reserved_host recovery action
04:28:00 <tpatil> #link : https://review.openstack.org/#/c/423072/
04:28:31 <tpatil> In the specs, Abhishek has proposed to use tooz library for acquiring locks
04:29:17 <tpatil> tooz library is meant to use if you want to access locks across distributed services
04:29:34 <tpatil> but in our case, masakari-engine will run on a single host
04:30:04 <tpatil> so it's better to add tooz support when we decide to run masakari-engine on multiple hosts
04:30:40 <tpatil> what you guys suggest?
04:30:56 <takashi> let me talk a little about its background
04:31:18 <takashi> to implement reserved host recovery method, we need to implement lock mechanism over reserved host
04:31:28 <takashi> so that we don't use same host for multiple failure notifications
04:31:44 <takashi> to implement lock mechanism there are two ways
04:32:09 <takashi> 1. Implement very simple lock mechanism using lock file(?). This is very simple, but can not manage lock among multiple nodes
04:32:17 <takashi> so we need to act/stb setup for masakari engine
04:32:30 <takashi> 2. Implement lock mechanis using tooz, which is used in cinder-volume act/act
04:32:53 <takashi> so that we realize act/act setup about masakari-engine
04:33:34 <tpatil> takashi: you are correct
04:33:47 <Dinesh_Bhor> reference: tooz use in openstack: http://codesearch.openstack.org/?q=tooz%3E%3D&i=nope&files=&repos=
04:33:56 <samP> takashi: make sense
04:33:57 <tpatil> tooz does supports both
04:34:27 <takashi> I had some discussions with tpatil in this morning, and IMO 1 looks better, because 2 takes some more time to complete, and we can do that migration to tooz later
04:37:20 <samP> Make masakari Act/Act would be nice, but we have consider other issues such as recovery flow management and state management.
04:38:24 <samP> I agree with takashi, we can implement lock with 1 and move to tooz later
04:38:49 <samP> as a part of make masakari act/act
04:40:24 <takashi> samP: +1
04:40:32 <takashi> does it make sense to other guys?
04:40:53 <tpatil> samP: +1
04:41:02 <rkmrHonjo> samP: +1.
04:41:08 <sagara> samP: +1
04:41:22 <abhishekk> +1
04:42:00 <samP> OK, any objections? if so, raise now
04:42:43 <samP> seems not, you may raise them later. for now lets make it confirm
04:43:08 <samP> abhishekk: could you please add above discussion to spec?
04:43:19 <abhishekk> samP: yes
04:43:32 <samP> abhishekk: great thanks
04:44:03 <tpatil> samP: when are you planning to cut stable/ocata branch?
04:44:28 <samP> #action abhishekk update the Implement reserved_host recovery action with locking method details
04:45:10 <samP> tpatil: 2/15 end of the date
04:45:25 <tpatil> samP: OK, thanks
04:46:00 <samP> so we can make the announce on 2/16
04:46:16 <tpatil> sounds good
04:46:59 <samP> tpatil: we have 2-3 days for just in case
04:47:16 <takashi> would be great if we can check merge status in next irc meeting
04:48:46 <samP> takashi: that would be great..
04:49:20 <samP> do we need a place to write them down before next irc?
04:50:28 <tpatil> samP: I will create an etherpad with Ocata priorities and add it to the agenda
04:50:48 <samP> tpatil: great thanks
04:51:36 <samP> #action tpatil Create an etherpad with Ocata priorities and add it to the next irc agenda
04:52:55 <samP> takashi: in previous meeting you mentioned about #openstack-masakari channel
04:55:12 <takashi> samP: I remember that I was just concerned about meeting time and proposed you to move to our local channel (because this channel is shared
04:55:32 <takashi> samP: do you mean that?
04:56:01 <samP> takashi: oh...ok then. I thought you was proposing to close that channel.
04:56:54 <takashi> samP: no. I don't know whether we should merge our channel to openstack-ha, but I don't feel big requirement for that
04:57:06 <takashi> because now it is working
04:57:08 <takashi> for us
04:58:51 <samP> takashi: yep.. IMO, lets leave it for a while, because some ppl come seek for help there
04:59:07 <takashi> samP: yes
04:59:32 <samP> OK then, is almost time.. any other things to discuss?
04:59:44 <takashi> no
04:59:46 <sagara> no
04:59:55 <rkmrHonjo> no
05:00:09 <tpatil> nothing from my end
05:00:28 <samP> Lets end this meeting. Thank you all...
05:00:36 <sagara> thanks
05:00:38 <takashi> thx
05:00:54 <samP> #endmeeting