04:00:54 <samP> #startmeeting masakari
04:00:55 <openstack> Meeting started Tue May 30 04:00:54 2017 UTC and is due to finish in 60 minutes.  The chair is samP. Information about MeetBot at http://wiki.debian.org/MeetBot.
04:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:00:58 <openstack> The meeting name has been set to 'masakari'
04:01:08 <samP> hi o/
04:01:12 <rkmrHonjo> hi
04:01:35 <samP> rkmrHonjo: hi
04:02:11 <samP> I haven't had enough time to change the agenda in wiki, just the date
04:02:35 <samP> seems like only few members are here..
04:02:43 <samP> Anyway lets start..
04:02:54 <samP> #topic critical bugs
04:03:30 <samP> #link https://bugs.launchpad.net/masakari/+bug/1690768
04:03:32 <openstack> Launchpad bug 1690768 in masakari "Notification status will be "error" if recovered instance was "resized"." [High,In progress] - Assigned to Dinesh Bhor (dinesh-bhor)
04:03:49 <samP> #link https://review.openstack.org/#/c/468770/
04:04:20 <samP> Thanks Dinesh ^^
04:04:29 <rkmrHonjo> I commented to the patch. It looks good to me.
04:04:38 <abhishekk> Hi all, we are facing network issue in office
04:04:43 <samP> rkmrHonjo: OK thanks
04:04:57 <rkmrHonjo> abhishekk: Hi
04:04:58 <samP> abhishekk: NP
04:05:34 <abhishekk> rkmrHonjo: hi
04:06:18 <abhishekk> my response might be slow as I am joining from mobile
04:06:32 <abhishekk> Sorry for inconvenience
04:06:46 <samP> abhishekk: NP, lets wait for a while...
04:07:55 <samP> rkmrHonjo: Yesterday you told that you wants to discuss something about VM_Status and how to recover them. Is this related to Dines's fix?
04:08:14 <samP> s/Dines/Dinesh
04:08:37 <rkmrHonjo> I'd like to talk about https://bugs.launchpad.net/masakari/+bug/1692435 . And the patch for that report is not pushed yet.
04:08:38 <openstack> Launchpad bug 1692435 in masakari ""ERROR" instances will be unexpectedly changed to "ACTIVE" when host failure happenes" [Undecided,New] - Assigned to Dinesh Bhor (dinesh-bhor)
04:09:00 <rkmrHonjo> But, I think that we should decide the policy for instance's state.
04:10:20 <rkmrHonjo> "Error" instance will be recovered as "ACTIVE" now. Is this correct or not?
04:10:47 <samP> rkmrHonjo: it is not correct
04:11:16 <abhishekk> rkmrHonjo: as per new solution this instance will be stopped
04:11:35 <samP> rkmrHonjo: In my point of view masakari should not try to activate error instances
04:11:56 <samP> For other states, https://bugs.launchpad.net/masakari/+bug/1690768/comments/5
04:11:58 <openstack> Launchpad bug 1690768 in masakari "Notification status will be "error" if recovered instance was "resized"." [High,In progress] - Assigned to Dinesh Bhor (dinesh-bhor)
04:12:04 <samP> #link https://bugs.launchpad.net/masakari/+bug/1690768/comments/5
04:12:37 <abhishekk> samP: rkmrHonjo: we are working on that and will push.patch today
04:12:48 <samP> abhishekk: thanks
04:13:11 <rkmrHonjo> abhishekk: thanks a lot. I'll review the patch.
04:13:15 <abhishekk> Testing is complete, just some refactoring is required
04:13:34 <abhishekk> rkmrHonjo: thanks :)
04:16:29 <samP> sorry
04:16:37 <samP> I was disconnected
04:16:42 <rkmrHonjo> oh
04:16:56 <abhishekk> rkmrHonjo: samP: does it sound good that instance which are in error state will be stopped after evacuation?
04:16:56 <samP> Any other bus to discuss?
04:17:12 <rkmrHonjo> no
04:17:37 <samP> abhishekk: my worry is, VM will start before you stop it.
04:18:22 <abhishekk> Yes, that is true and we dont have any controll over that :(
04:19:03 <rkmrHonjo> samP: I think that we can't avoid the behaviour.
04:19:22 <samP> abhishekk: yep.. in current nova code, we cant
04:20:12 <samP> However, does it make sense to stop after rebuild in evacuation?
04:21:20 <samP> I mean, if the instance is in stopped state, then it will evacuate to stopped state. not for active state. right?
04:21:32 <abhishekk> samP: yes
04:22:40 <samP> Therefore, we can consider 2 options, (1) stop it before evacuate, (2) evacuate to given VM state
04:23:55 <samP> In (1), I dont think we nova API can stop the instance and change its status to "stopped", with broken compute-node
04:24:38 <samP> On the other hand, (2) needs to fix nova.
04:25:21 <samP> matter of fact, need to fix nova for (1) also
04:25:24 <abhishekk> samP: right, but I doubt nova will accept this
04:26:04 <samP> abhishekk: I could understand the reason for (1)
04:26:31 <samP> abhishekk: Do you think (2) also not acceptable for nova?
04:26:54 <abhishekk> samP: for 2 as well that is expected behavior from nova's point of view
04:28:19 <samP> abhishekk: right..that may be the expected behavior... but not what we expect..:)
04:28:38 <abhishekk> samP: nova is not allowing evacuation of instances which are having vm state other than active, error and stop
04:28:51 <abhishekk> samP: :)
04:29:28 <rkmrHonjo> Or, modify Reset State API? For example, cinder's Reset state API can change the status freely.
04:29:54 <samP> rkmrHonjo: I think in nova, we had this discussion...
04:31:16 <abhishekk> Because in case of resize it will be overhead to know to which flavor instance has resized and will require to perform whole action again
04:32:27 <abhishekk> rkmrHonjo: this will also not acceptable because changing vm_state to resized or shelved does not make any sense
04:33:04 <rkmrHonjo> abhishekk: thank you for explaining.
04:33:56 <samP> abhishekk: thanks
04:34:14 <samP> I could not find the like to previous discussion..
04:34:18 <samP> anyway..
04:35:53 <samP> Let's think about this... for next week I will crate some details on etherpad for this.
04:36:03 <abhishekk> Ok
04:36:14 <rkmrHonjo> samP: tahnks.
04:36:19 <abhishekk> So can we push the patch or not
04:36:23 <rkmrHonjo> s/tahnks/thanks/g
04:36:46 <abhishekk> Because in current patch we are stopping the instance after evacuation
04:37:17 <samP> abhishekk: you can push the patch, with current nova code we could not do nothing else
04:37:46 <abhishekk> samP: ok
04:38:26 <samP> #action samP create doc for how to rescue in to stopped state
04:38:57 <samP> Any other bugs to discuss?
04:39:23 <abhishekk> No
04:39:30 <samP> if not, let go to Discussion points
04:39:37 <samP> #topic Discussion
04:40:03 <samP> abhishekk: thanks for update on recovery-method-customization
04:40:16 <samP> I will review new changes
04:40:55 <abhishekk> samP: ok
04:41:00 <samP> Any updates on other topics?
04:41:29 <abhishekk> For destructive testing we are checking rally-hooks
04:41:53 <samP> abhishekk: thanks
04:42:02 <abhishek_k> https://docs.openstack.org/developer/rally/plugins/implementation/hook_and_trigger_plugins.html#problem-description
04:42:06 <abhishek_k> #link https://docs.openstack.org/developer/rally/plugins/implementation/hook_and_trigger_plugins.html#problem-description
04:42:59 <samP> abhishekk: thanks.. (not directly related to masakari... right?)
04:42:59 <abhishek_k> using rally_hooks it is possible to trigger some faults like restart rabbitmq, openstack services, mysql etc
04:43:42 <abhishek_k> samP: yes :)
04:44:06 <abhishek_k> samP: sorry for mixing :)
04:44:11 <samP> abhishek_k: Lets make a another place for destructive testing topics..
04:44:25 <rkmrHonjo> samP: +1
04:44:28 <abhishek_k> samP: agree
04:44:42 <sagara> agree
04:44:43 <samP> abhishek_k: NP.. I will send a mail to ML.
04:44:59 <abhishek_k> samP: yes
04:45:13 <samP> so we can discuss how to proceed with that...
04:45:16 <samP> sorry..
04:45:47 <samP> abhishek_k: BTW, thank you for the work
04:46:09 <abhishek_k> samP: thanks :)
04:46:16 <rkmrHonjo> samP: What kind of tag will be added to the mail? QA?
04:46:26 <samP> from my side, Force Stonith
04:46:31 <samP> ah..
04:46:40 <samP> rkmrHonjo: It will be QA and LCOO
04:47:02 <samP> from my side, Force Stonith is almost done. I will push it soon
04:47:11 <rkmrHonjo> samP: ok, I got it.
04:47:37 <samP> Other than that, I think no more updates on Pike work items
04:48:10 <abhishek_k> samP: thank you, we will like to understand how it will work :)
04:48:47 <abhishek_k> samP: need to review doeumentation patch
04:49:13 <samP> abhishek_k: thanks.. I will do that
04:49:21 <abhishek_k> samP: #link https://review.openstack.org/#/c/459516/
04:49:30 <abhishek_k> samP: thank you
04:49:42 <samP> #action samP review documentation patch
04:51:17 <samP> if no other topics, lets move to AOB
04:51:23 <samP> #topic AOB
04:52:04 <samP> Greg was trying to push new spec for Intrusive Instance Monitoring.
04:52:34 <samP> However, he was having some problems with git
04:52:57 <samP> #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg106194.html
04:53:03 <samP> #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg106186.html
04:53:44 <samP> I couldn't find any problem with spec repo side...
04:53:52 <rkmrHonjo> I read that mail, but I have no idea why he failed.
04:54:02 <Dinesh_Bhor> samP: me too
04:54:17 <samP> me neither
04:54:36 <samP> if you find some useful info, please let him know..
04:55:03 <rkmrHonjo> samP: sure.
04:55:20 <samP> may be rebase and do it again will do the trick
04:55:35 <samP> lest wait for the replay..
04:55:51 <samP> Any other topics?
04:56:10 <abhishek_k> samP: nothing from us
04:56:16 <rkmrHonjo> no
04:56:20 <Dinesh_Bhor> Masakari PY27 job is failing right now. This patch unblocks it: https://review.openstack.org/#/c/468767/ It will be great if someone approves that.
04:56:39 <sagara> Sorry, I have no..
04:57:16 <samP> Dinesh_Bhor: done
04:57:27 <Dinesh_Bhor> samP: thanks
04:59:23 <samP> Its almost time and let's finish the meeting here.. please bring other topics to ML or #openstack-masakari
04:59:28 <samP> Thank you all
04:59:33 <samP> #endmeeting