04:00:50 <samP> #startmeeting masakari
04:00:51 <openstack> Meeting started Tue Feb 28 04:00:50 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:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:00:54 <openstack> The meeting name has been set to 'masakari'
04:01:13 <samP> Hi all, right after PTG..
04:01:25 <samP> lets start with bugs...
04:01:39 <samP> #topic open bugs
04:01:48 <tpatil> # link: https://bugs.launchpad.net/masakari/+bug/1663513
04:01:48 <openstack> Launchpad bug 1663513 in masakari "Masakari failed to rescue PAUSED instances" [Undecided,Confirmed] - Assigned to Dinesh Bhor (dinesh-bhor)
04:01:48 <Dinesh_Bhor> Hi all
04:02:28 <tpatil> Need feedback on Dinesh's comment on LP bug
04:03:24 <Dinesh_Bhor> # link: https://bugs.launchpad.net/masakari/+bug/1663513/comments/5
04:03:24 <openstack> Launchpad bug 1663513 in masakari "Masakari failed to rescue PAUSED instances" [Undecided,Confirmed] - Assigned to Dinesh Bhor (dinesh-bhor)
04:04:31 <sagara> I agree Dinesh opinion. I also Masakari should maintain the vm_state before recovery.
04:04:56 <samP> I agree that we need to maintain the consistency for VM state. Hoever rescue VM has same issue, right?
04:05:27 <Dinesh_Bhor> samP: yes
04:06:01 <samP> OK, then solution is, store the previous state of the VM and, return it to previous state after doing recovery
04:06:49 <samP> I mean, the solution should be a general one for all cases.
04:07:38 <tpatil> samP: At the time of instance recovery action, if the vm is in paused vm state, then what should be the final vm state after executing recovery action?
04:08:26 <tpatil> samP: this question is in context of the scenario highlighted in above LP bug
04:09:25 <samP> tpatil: I think we can not use reset-state api to set the state to PAUSED, right?
04:09:57 <Dinesh_Bhor> samP: yes, we can only set to error or active
04:11:31 <samP> for instance recovery action it should be, paused-> active -> paused
04:12:46 <samP> tpatil: IMO, final state should be paused
04:12:54 <tpatil> samP: OK, for all other cases, vm state will go into ACTIVE status
04:13:23 <tpatil> samP: for above LP bug, the final vm_state will be PAUSED
04:13:38 <samP> tpatil: yes.
04:13:51 <tpatil> samP: Thank you
04:13:52 <sagara> I think PAUSED VM are going to lost their memory, and it not working before recovery, so is it good to remain it SHUTDOWN?
04:14:43 <tpatil> sagara: You have a good point there
04:15:39 <samP> sagara: correct. once we start the VM, we will lose the internal state of the VM
04:17:01 <samP> on the other hand, if shutdown it, it will not be the expected recovery
04:17:44 <tpatil> There should be some indication to the user that the instance has been recovered due to qemu process termination
04:19:09 <tpatil> if we keep the vm_state into PAUSED state
04:21:26 <tpatil> What would operators do if such problem occurs at present?
04:21:51 <samP> if the VM in PAUSED state, doing nothing would be a solution?
04:22:25 <samP> tpatil: I think currently we are not using that API, but let me confirm it
04:22:56 <sagara> samP: please confirm it.
04:23:08 <sagara> It might be nice to have some configuration. operator(admin) or user can specify VM recovery state, system default and per VM or per segment.
04:23:10 <samP> sagara: sure, I will do.
04:25:32 <samP> I will ask around for how ops handaling this issue, including sagara's point.
04:25:59 <samP> And, I will update the LP for this.
04:26:07 <tpatil> samP: Ok, please add your feedback on the LP bug
04:26:21 <tpatil> samP: thank you
04:26:49 <samP> #action samP Add FP to https://bugs.launchpad.net/masakari/+bug/1663513
04:26:49 <openstack> Launchpad bug 1663513 in masakari "Masakari failed to rescue PAUSED instances" [High,Confirmed] - Assigned to Dinesh Bhor (dinesh-bhor)
04:27:18 <samP> Other bugs?
04:28:08 <sagara> Takahara reported a bug
04:28:26 <sagara> # link: https://bugs.launchpad.net/masakari/+bug/1667246
04:28:26 <openstack> Launchpad bug 1667246 in masakari "When masakari-engine adds reserved_host to aggregate, 404 error occurs" [Undecided,Fix released] - Assigned to takahara.kengo (takahara.kengo)
04:29:14 <sagara> Honjo and me, already reviewed this patch, and yesterday it merged.
04:30:03 <samP> sagara: thanks
04:30:50 <tpatil> samP: Do we need to back port this patch to stable/ocata branch?
04:31:16 <samP> tpatil: thatz what im thinking now
04:32:58 <samP> I think this is critical and better to back port to oacata. any objections?
04:33:05 <sagara> samP, tpatil: I think it is high or critical bug. reserved host feature could not work without this patch, so we must do backport that stable/ocata.
04:34:14 <samP> if no objections, lets back port this to stable/ocata
04:34:44 <sagara> samP: I agree to backport.
04:34:55 <tpatil> samP: sure, we will upload patch today
04:35:31 <samP> #action tpatil backport https://review.openstack.org/#/c/437312/ to stable/ocata
04:35:45 <samP> tpatil: I hv just put that action to you.
04:36:21 <tpatil> samP: ok
04:36:27 <samP> tpatil: thank you
04:37:31 <tpatil> samP: we need functional test soon to find out such issues
04:38:49 <samP> tpatil: agree, lets discuss pike work items including functional tests.
04:39:00 <tpatil> samP: sure
04:39:56 <samP> tpatil: sorry that I didn't have time to sort the things. Lets have that discussion on next week IRC, I'll create a etherpad for this.
04:40:17 <samP> any other bus to discuss?
04:40:22 <tpatil> samP: Ok
04:40:44 <sagara> samP: ok
04:41:47 <samP> Is this still valid https://bugs.launchpad.net/masakari-monitors/+bug/1661517 ?
04:41:47 <openstack> Launchpad bug 1661517 in masakari-monitors "masakari-instancemonitor fails to start with error “required config option auth-url”" [Undecided,New] - Assigned to Pooja Jadhav (poojajadhav)
04:42:55 <tpatil> samP: I will request Pooja to try it on the latest masakari-monitors code
04:43:06 <samP> tpatil: sure, thanks
04:43:30 <samP> if no other bugs, lets jump into discussion
04:43:42 <samP> #topic discussion points
04:44:36 <samP> As I said previously, I will create a etherpad for pike work items. Please add any item you would like to work or any proposals are welcome.
04:45:09 <tpatil> samP: Ok
04:45:09 <samP> I would like to discuss those items and prioratize them in our next IRC.
04:45:27 <sagara> samP: OK
04:47:10 <samP> #link https://etherpad.openstack.org/p/masakari-pike-workitems
04:47:52 <samP> Here ^^ is the link for Pike work items
04:48:52 <sagara> as of now, it has no contents :)
04:49:10 <samP> I will also create wiki item for pike release schedule which will be same as other official projects
04:49:53 <samP> sagara: Just created it :), I will populate it with my thoughts later..
04:50:11 <tpatil> I will add " Implement auto_priority and rh_priority recovery_methods" as pike work item. Dinesh has already pushed patch for this implementation
04:50:24 <tpatil> #link : https://review.openstack.org/#/c/433669
04:50:39 <samP> tpatil: thanks, that will do
04:51:28 <samP> any other points to discuss?
04:52:00 <samP> ah.. I will share PTG updates for masakari in mail.
04:52:53 <samP> if no other topics, lets jump in to AOB
04:52:58 <samP> #topic AOB
04:57:23 <samP> Nothing else to discuss, lets finish the meeting..
04:57:54 <samP> Thank you all for your time...
04:57:54 <tpatil> samP: yes
04:58:02 <sagara> samP: I heard from you, TC are willing to add mentor to our project. When does it starts?, do we need anything to prepare?
04:59:09 <samP> sagara: I have reach them first. I will post that details in mail to you all.
04:59:40 <samP> sagara: no need to specially prepare
04:59:53 <sagara> samP: thank you
05:00:02 <samP> OK, then its almost time, lest finish
05:00:11 <samP> thank you all...
05:00:38 <tpatil> Thank you.
05:00:39 <samP> #endmeeting