04:00:19 <samP> #startmeeting masakari
04:00:19 <openstack> Meeting started Tue Jul 18 04:00:19 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:00:24 <openstack> The meeting name has been set to 'masakari'
04:00:31 <samP> Dinesh_Bhor: hi
04:00:40 <samP> hi all ..o/
04:00:40 <abhishekk> o/
04:00:46 <Dinesh_Bhor> hi all
04:00:49 <samP> let's start
04:01:09 <samP> #topic Critical Bugs
04:01:18 <samP> Any bugs to discuss?
04:02:20 <samP> if not, lets move to Discussion
04:02:30 <samP> #topic Discussion Points
04:02:59 <samP> Dinesh_Bhor: thanks for the remove on_shared_storage patch
04:03:45 <samP> abhishekk: any updates from nova or Ops about evacuate the "resized" VMs
04:04:04 <abhishekk> samP: regarding resize issue I have got reply from Jay Pipes, http://lists.openstack.org/pipermail/openstack-operators/2017-July/013932.html
04:04:17 <samP> abhishekk: yep
04:04:42 <abhishekk> he suggested to revert the resize instead of setting it to error and then do resize again after evacuation
04:05:17 <abhishekk> Should we follow this approach?
04:05:42 <rkmrHonjo> Could we revert the resize when host is down?
04:06:01 <abhishekk> If yes I have couple of doubts which I have updated on the redmine ticket
04:06:11 <samP> situation is: destination fail. If we revert it and re do the resize, the no evacuate needed. right?
04:06:38 <abhishekk> rkmrHonjo: right
04:06:57 <abhishekk> samP: ^^^
04:07:21 <tpatil> when you revert, masakari is not aware whether host A is up or down
04:07:35 <samP> We could revert it if destination down. do we consider the situation where source host down?
04:08:11 <tpatil> if revert is successful, then we should also note down the new flavor used to resize the instance and try resize api again
04:09:09 <abhishekk> samP: if source host is down then reverting will fail and then can we mark the notification as failure?
04:09:25 <samP> tpatil: That is true. we have to find which flavor used
04:10:45 <samP> abhishekk: mark notification as failure = hand it over to operator?
04:13:11 <tpatil> samP: reattempt in periodic task to recover the instance and if its fails again, it will be handed over to the operator
04:13:12 <samP> I think it is worth considering revert on destination failure as Jay said.
04:14:44 <samP> tpatil: thanks. it seems to me, that revert will fail because source node is down, and it will handed over to operator anyway..
04:15:21 <tpatil> samP: As per Jay`s suggestion, it's possible to bring the instance to the original state i.e. resized
04:16:14 <samP> tpatil: for destination node down: yes
04:16:44 <samP> tpatil: is it still possible where source node down?
04:17:33 <tpatil> samP: you are correct, if source compute is down, then it will be handed over to the operator after second attempt
04:17:53 <samP> tpatil: OK
04:18:21 <tpatil> abhishekk: correct me if I'm wrong
04:18:38 <abhishekk> tpatil: you are right
04:20:15 <abhishekk> just to confirm, we need to revert the resize if vm state is down and then resize it again with new flavor
04:20:15 <samP> humm.. before resize confirmed, if source node is down, then simply resize confirm wil move the instance to destination node?
04:20:59 <samP> abhishekk: yes
04:21:45 <tpatil> abhishekk: you mean vm_state is resized, correct?
04:22:24 <tpatil> if vm_state is resized, revert and then resize it again with the new flavor
04:23:09 <abhishekk> tpatil: yes
04:23:19 <samP> if destination host is down: if vm_state is resized, revert and then resize it again with the new flavor
04:23:20 <tpatil> abhishekk: ok
04:23:41 <samP> if destination source is down: mark the notification as failure?
04:24:22 <tpatil> samP: we cannot can resize confirm because the destination compute host is down and hence masakari got the request to evacuate the instance
04:24:30 <tpatil> s/can/call
04:25:06 <samP> tpatil: sorry, mistake
04:25:21 <samP> if source host is down: mark the notification as failure?
04:25:24 <abhishekk> samP: if source is down then we will set the notification as failed so that it will picked by periodic task for second attempt of processing
04:26:24 <samP> abhishekk: OK
04:26:35 <samP> abhishekk: tpatil: thanks
04:27:58 <abhishekk> ok, we will make changes as per discussion
04:28:27 <samP> OK lets proceed with, resize revert and let's see any other points to consider
04:28:37 <samP> abhishekk: thank you.
04:29:43 <abhishekk> Honjo san has given comment on api documentation patch, https://review.openstack.org/459516
04:29:43 <samP> rkmrHonjo: What it the status of exclude "ERROR" state VMs from rescue
04:30:10 <samP> abhishekk: about the place for "please use shared storage"?
04:30:11 <rkmrHonjo> I sent a mail to dev ML. But there were no reactions.
04:30:29 <abhishekk> no do not use openstackdocs theme
04:30:31 <rkmrHonjo> I'll write a bug report(or blueprint) if there were no objections.
04:30:44 <rkmrHonjo> oops, sorry abhishekk
04:31:13 <abhishekk> to implement that I need to restructure entire api documentation
04:31:27 <abhishekk> rkmrHonjo: no problem
04:31:32 <samP> abhishekk: ah..yes. we can not use openstackdocs theme
04:31:56 <samP> abhishekk: it is only for official openstack projects
04:32:19 <abhishekk> samP: I will restructure it
04:32:32 <samP> abhishekk: sorry... please
04:32:52 <samP> abhishekk: at the time we start this work, there were no such strong restrictions.
04:33:00 <abhishekk> samP: no problem, I will refer glare or blazar documentation for reference
04:33:16 <samP> abhishekk: sure
04:33:27 <abhishekk> samP: yes, thats why we have followed nova documentation
04:34:11 <abhishekk> that's it we can move to next point
04:34:12 <samP> abhishekk: ok. lets remove that theme
04:34:20 <samP> abhishekk: thanks
04:34:32 <samP> rkmrHonjo: sorry, I missed your mail.
04:34:40 <samP> rkmrHonjo: I will replay it soon.
04:35:03 <rkmrHonjo> samP: NP. thanks.
04:35:45 <samP> rkmrHonjo: I think we do not need BP for this. lets discuss in the ML and, then we could agree on how to fix this.
04:36:08 <rkmrHonjo> samP: OK. I agree.
04:37:02 <samP> About recovery method customization
04:38:12 <abhishekk> needs review on spec
04:38:30 <samP> abhishekk: thank you for new patch set. No reply from Mistral. I will review the specs
04:38:43 <abhishekk> samP: thank you
04:39:50 <samP> Add db purge support looks good. thanks for the review..
04:40:22 <samP> I will approve this soon.
04:40:24 <samP> thanks.
04:41:09 <samP> In the pike work items, my items are still pending..
04:41:27 <samP> I will push them soon, sorry for the delay.
04:42:41 <samP> Other specs are under review and I will process them..
04:43:01 <samP> Any other things to discuss on specs?
04:43:28 <abhishekk> no
04:43:33 <rkmrHonjo> no
04:43:36 <sagara> prevent from flapping is not yet
04:45:31 <samP> sagara: I cant remember the conclusion of our last discussion on "prevent from Flapping"
04:45:56 <samP> sagara: is this still valid proposal?
04:46:49 <samP> sagara: due to new masakari architecture, I think we agree to reconfirm the validity of this feature
04:47:54 <sagara> samP: OK, I see, Please rethink it together
04:47:58 <samP> sagara: If it is still valid, then please proceed with the proposal..
04:48:01 <samP> sagara: sure..
04:48:24 <samP> #topic AOB
04:48:45 <samP> Any other topics to discuss?
04:49:19 <samP> I submit 2 presentations on VMHA to summit.
04:49:38 <samP> one with Adam@Suse and other one by myself..
04:50:42 <abhishekk> great
04:50:43 <samP> There is another panel discussion proposal on openstack HA
04:51:21 <samP> I couldn't put my name on that due to limit exceed.
04:52:06 <samP> However, if it will up, then I may have ask some of us to attend to that panel as speaker
04:52:11 <samP> I will let you all know..
04:52:58 <samP> s/may have/will/
04:53:11 <tpatil> samＰ:Ｓｕｒｅ
04:53:33 <samP> Thatz all from my side
04:54:20 <samP> if no other topics to discuss, then lets finish the meeting.
04:54:48 <abhishekk> ok
04:54:49 <samP> please use #openstack-masakari or ML with [masakari] for extended discussions..
04:54:55 <Dinesh_Bhor> This seems intresting to note from masakari side: https://review.openstack.org/#/c/462521/
04:56:08 <samP> Dinesh_Bhor: thanks.. this is interesting..
04:56:14 <Dinesh_Bhor> I will keep watch on this
04:56:15 <rkmrHonjo> ah. Live migration already has rollback action. That patch will implement rollback action to cold migration/resize.
04:56:28 <rkmrHonjo> rollback action=revert
04:57:24 <samP> Dinesh_Bhor: thanks.. let watch this.
04:58:30 <samP> OK then... if nothing else..let's endmeeting
04:58:35 <samP> Thank you all....
04:58:39 <rkmrHonjo> thank you.
04:58:45 <Dinesh_Bhor> thanks to all
04:58:56 <samP> #endmeeting