04:00:51 #startmeeting masakari 04:00:52 Meeting started Tue Dec 10 04:00:51 2019 UTC and is due to finish in 60 minutes. The chair is samP. Information about MeetBot at http://wiki.debian.org/MeetBot. 04:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 04:00:55 The meeting name has been set to 'masakari' 04:01:36 Hi all for masakari 04:01:42 Hi 04:01:50 tpatil: Hi 04:02:11 #topic Critical bugs or patches 04:02:33 Any critical bugs or patches need to discuss here? 04:02:50 #link : https://bugs.launchpad.net/masakari/+bug/1854323 04:02:50 Launchpad bug 1854323 in masakari "inconsistent output for 'openstack segment host show|update'" [High,New] - Assigned to Shilpa Devharakar (shilpasd) 04:03:11 I have marked this bug as High priority and Shilpa is working on fixing this issue 04:03:26 The patch will be pushed sometime in this week 04:04:16 tpatil: thanks, this is the one posted by Jan 04:04:37 samP: yes, that's correct 04:05:07 #link : https://review.opendev.org/#/c/675734 04:05:43 I have posted one comment on this patch and awaiting for author to response on my comment 04:06:27 In there, I have suggested to use host instead of hypervisor_hostname to solve the issue. 04:07:10 tpatil: OK, I will try to ping Lian Young for this. 04:09:14 I think but with that change, it might break compatibility. We will need to discuss on that part 04:12:37 tpatil: agree. I remove the +2 on this. Let's try to contact author for discussion. 04:16:19 #link : https://bugs.launchpad.net/python-masakariclient/+bug/1854903 04:16:19 Launchpad bug 1854903 in python-masakariclient "masakariclient not supporting filter parameters for multiple times" [Undecided,New] - Assigned to Shilpa Devharakar (shilpasd) 04:17:17 basically masakari client allows to specify --filter recovery_method=auto recovery_method=rh_priority, but masakari treats it as a single recovery_method 04:17:46 $openstack segment list --filter recovery_method=auto recovery_method=rh_priority 04:19:29 when it calls REST API, it send url query params something like : instance-ha/v1/segments?recovery_method=%5Bu%27auto%27%2C+u%27rh_priority%27%5D 04:19:55 i.e. segments?recovery_method=auto,rh_priority 04:20:30 but masakari API treats it as a single recovery_method ii.e. "auto,rh_priority" 04:20:38 got it. the problem is, it neglect the second filter 04:20:41 and it will return empty list in such case 04:21:11 so I think we should fix this issue in masakari client by deprecating --filter 04:21:44 and simply using new options like "openstack segment list --recovery_method auto --host xyz" 04:23:43 or we can also fix this issue in masakari-api, but in that case we will need to consider recovery method as auto or rh_priority 04:24:15 I would like to know how do we want to fix this issue 04:25:19 I would prefer option#1, because in masakari this functionality wasn't available but still added in masakariclient 04:25:57 tpatil: thanks for discussing this bug 04:26:27 sicne openstack does not have it, I think deprecating is OK 04:27:40 what gonna happen if, openstack segment list --recovery_method auto --recovery_method rh_priority --host xyz 04:27:54 in current master? 04:27:59 yes. 04:28:03 empty list 04:28:26 that is for --filter right? 04:29:05 if we give two --recovery_method parameters for segment list command 04:29:28 today these options doesn't exist 04:30:21 if passed it will give an error: openstack segment list: error: unrecognized arguments: --recovery_method auto 04:30:37 OK, my misunderstanding. 04:31:09 option #1 is to deprecate --filter option and add new options recovery_method, host etc.. 04:31:26 Then what we sould do is, deprecating --filter and enable the new filtering options 04:31:39 am I right? 04:31:48 yes, that's correct 04:32:36 option #2, masakari-api can split the recovery_method=auto,rh_prioirty into two and consider it as auto or rh_prioirty 04:34:01 in URL query parameter, if we get recovery_method=auto,rh_prioirty, then it would return segments matching recovery method auto or rh_priority. 04:35:03 option #2 about changing the masakari-api? 04:35:15 samP: yes 04:36:16 IMHO, in option #1 and #2, we have find a way to support multiple values for single parameter, 04:36:19 such as, 04:36:28 --recovery_method auto --recovery_method rh_priority 04:36:38 --filter recovery_method=auto recovery_method=rh_priority 04:37:32 From client side, we can call masakari-api for multiple times and merge the result 04:37:49 or change the masakari-api as you proposed. 04:39:01 samP: passing recovery_method multiple times is already supported by masakariclient but it doesn't get the expected result from masakari-api, so we should fix this issue in masakari-api. 04:39:31 I think that's what you want to suggest here, is it correct? 04:40:06 tpatil: thanks, that's what I wanted to say. :) 04:40:42 Fixing the masakari-api is more appropriate in this case 04:40:55 samP: understood, we will fix this issue in masakari-api 04:41:05 tpatil: thanks 04:41:28 Any other issues? 04:42:44 No 04:42:57 #topic AOB 04:43:41 We need to list up Ussuri work itmes. 04:44:23 just one info before we move on U release items 04:44:38 tpatil: sure 04:45:19 about the above bug, if you call openstack --debug segment list --filter recovery_method=auto --filter recovery_method=rh_priority 04:45:49 the url query parameters passed are: /segments?recovery_method=auto&recovery_method=rh_priority 04:46:15 so it only considers recovery_method=rh_priority, as we get query parameters in dict form 04:47:10 if you want pass recovery method twice, then we would need change in masakari client to pass recovery_method=auto,rh_priority 04:47:40 tpatil: Got it, Thanks for the update 04:47:40 and in masakari-api side, we will need to split it based on the comma separator. 04:47:58 correct 04:48:04 so in short, we will need to make changes in both client and api 04:49:53 about Ussuri work items we want to implement blueprint 04:49:56 #link : https://blueprints.launchpad.net/masakari/+spec/evacuate-non-recovery-instances-in-shutoff-status-at-host-failure-except-specified-tenants 04:50:17 We will propose specs for this blueprint soon 04:50:44 I have just create a etherpad for list up the items. 04:50:48 https://etherpad.openstack.org/p/masakari-u-workitems 04:51:55 There are some PBs already proposed for U. Let's list them up and discuss on our next IRC meeting 04:53:20 Sure, I have added above blueprint in the etherpad 04:53:36 tpatil: Thanks 04:54:17 Statscowski: posted a question on #openstack-masakari 04:54:39 Hello. newb question. We deployed openstack with msakari through kolla. Is the horizon webui enough to configure masakari? if so, │ 04:54:40 │ | we are having toruble triggering a successful failover 04:56:09 Does kolla supports installation and deployment of masker-hostmonitor? 04:56:09 Any known issues with horizon webui for configure masakari? 04:56:34 horizon webui means masakari-dashboard? 04:56:35 tpatil: I think it does not support install and config hostmonitor 04:56:41 tpatil: yes 04:57:19 masakari-dashboard will only allows you to configure failoversegment and add hosts to it, also you can see the notification details 04:57:49 if hostmonitor support isn't available in kolla, then compute failureover won't work 04:57:57 compute node failure won't work 04:58:09 I think the answer is, only masakari-dashboard is not enough 04:59:10 samP: Yes 04:59:13 you have to configure masakari and setup masakari-hostmonitor (if not supported in kolla) 04:59:48 no time left to give a detail answer. Statscowski: please ask on ML 04:59:55 we dont have much time left 05:00:01 let's finish the meeting here 05:00:07 Thank you all for your time. 05:00:11 #endmeeting