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