04:01:12 <samP> #startmeeting masakari
04:01:13 <openstack> Meeting started Tue Feb  6 04:01:12 2018 UTC and is due to finish in 60 minutes.  The chair is samP. Information about MeetBot at http://wiki.debian.org/MeetBot.
04:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:01:17 <openstack> The meeting name has been set to 'masakari'
04:01:24 <Dinesh_Bhor> Hi all
04:01:38 <samP> Hi all
04:01:44 <samP> let's start
04:02:11 <samP> #topic High Priority Items
04:02:19 <samP> About Release
04:02:57 <samP> I had a discussion with release team and agree to follow independent release model for Queens
04:03:28 <samP> Form next cycle, we will follow the cycle-with-milestones
04:03:29 <tpatil> Ok
04:03:38 <samP> #link https://releases.openstack.org/reference/release_models.html
04:03:55 <tpatil> samP: Sure
04:04:02 <tpatil> samP: Service type patches are up for review, do you want this change in Queens cycle?
04:04:20 <samP> tpatil: that's one thing I would like to discuss
04:05:18 <samP> since requirements are freezed, if we merged them then we have to propose FFE to requirements
04:06:23 <samP> on the other hand, instance-ha has alias `ha`
04:06:24 <tpatil> samP: IMO, it's not a blocker.it can be done early Rocky release.What do you think?
04:07:57 <samP> tpatil: are you proposing to update requirement manually, till Rocky start?
04:10:32 <tpatil> samP: If we don't want to depend on requirements, then that's one way to merge service type change in queens cycle. But I don't think we should go in that way
04:11:07 <tpatil> my main question is, do you want to change service_type in Queens cycle?
04:12:01 <samP> tpatil: I would like to postpone it to Rocky, if no objections
04:14:25 <tpatil> If service type change is not a blocker for other OpenStack projects, then I think it's ok to merge it in early Rocky release
04:15:40 <samP> for my understanding it would not be a blocker for other projects.
04:16:10 <samP> OK, then let's land it on early Rocky.
04:16:36 <tpatil> samP: Sure
04:16:56 <samP> Since we are following the independent release model, I would like to propose closing dates for Queens.
04:17:05 <Dinesh_Bhor> Is there any existing openstack service sharing the same "HA" service_type?
04:17:26 <samP> for Masakari, stable/queens will be created on 2/23
04:18:07 <samP> Dinesh_Bhor: none that i known of
04:18:41 <Dinesh_Bhor> samP: okay, then there is no issue. We can update the service_type in next release.
04:19:05 <samP> Please do not merge patches for openstack/masakari after 2/20
04:19:44 <samP> if you would like to merge something after 2/20, please discuss with me.
04:20:29 <samP> For masakari-monitors, python-masakariclient stable/queens will be created on 2/13
04:20:29 <tpatil> samP: When will stable/queen branch be cut for masakari projects?
04:20:40 <tpatil> samP: Ok
04:20:47 <samP> tpatil: it will be 2/23
04:21:27 <samP> Please do not merge any patches for masakari-monitors and python-masakariclient after 2/9
04:21:30 <tpatil> samP: One question related to service type
04:21:37 <samP> tpatil: sure,
04:21:53 <tpatil> if someone is using masakari for the first time, then they would need to add service as 'ha' and not 'instance-ha', correct?
04:22:12 <samP> tpatil: yes
04:23:43 <tpatil> samP: Does operator refers service-types-authority project for creating services for OpenStack deployment?
04:24:49 <tpatil> If yes, then we need to confirm masakari will work using alias 'ha'.
04:24:50 <samP> tpatil: in that case we have `ha` alias to `instance-ha`
04:25:20 <tpatil> I will confirm this point from my end
04:25:37 <samP> tpatil: thank you. that will be great.
04:27:16 <samP> tpatil: if there are any issues, could you please share. So, we could merge them to Queens and fix the related problems manually.
04:27:34 <tpatil> In Keystone Service db table, I can see only type column to store service type
04:27:57 <tpatil> Need to check how to specify alias when you add a service
04:28:21 <tpatil> samP: I will update my findings
04:29:46 <samP> "API consumer cannot find a given service-type in the service-catalog, they are directed to try the list of aliases" need to find out more about it.
04:30:56 <samP> tpatil: thanks. I will take a look on this.
04:30:59 <tpatil> since consumers of masakari service are python-masakariclient and masakari-monitors, there shouldn't be any issues
04:32:29 <samP> tpatil: currently, yes. if someone would like to call masakari API from their custom monitors, then that would be the situation
04:33:34 <tpatil> samP: in that case, they would need to follow service type authority guidelines to try using alias
04:34:20 <samP> tpatil: correct
04:35:29 <tpatil> samP: So it's ok to merge service type changes in early Rocky, correct?
04:36:48 <samP> tpatil: Correct. I do not see any problem with that.
04:36:55 <tpatil> samP: Ok
04:38:17 <samP> All the details about release is in today's meeting wiki
04:38:28 <samP> #link https://wiki.openstack.org/wiki/Meetings/Masakari#High priority items
04:39:15 <samP> which is not a good place to hold those info. I will put those info in masakari wiki page and send them to ML
04:39:33 <samP> if you have any questions or requests please let me know.
04:39:43 <tpatil> samP :Sure
04:40:51 <samP> I would like to merge operators guide documentation in Queens.
04:40:57 <samP> #link https://review.openstack.org/#/c/489095/
04:40:58 <patchbot> patch 489095 - masakari-monitors - Masakari-monitors operator's documentation
04:42:12 <samP> I have already read the doc, only have few comments. I will put my review comments asap.
04:42:50 <samP> #topic Bugs and patches
04:43:01 <samP> Any bugs or patches to discuss?
04:44:26 <samP> Horizon Plugin, what is happening to this patch?
04:44:32 <samP> #link https://review.openstack.org/#/c/528647/
04:44:33 <patchbot> patch 528647 - masakari-dashboard - Initial UI-Cookiecutter commit
04:45:11 <samP> I thought I have merged it :)
04:45:50 <tpatil> Zuul requirements jobs are failing after workflow +1
04:45:56 <tpatil> need to merge it again
04:46:39 <tpatil> In Queens release, are you planning to release masakari-dashboard?
04:47:26 <samP> tpatil: no. I think there is nothing to release yet. right?
04:47:39 <tpatil> samP: Correct
04:48:19 <samP> tpatil: it's first release will be in Rocky
04:49:11 <tpatil> samP: Ok, I will review cookie cutter patch and vote +2 if no comments from my end
04:49:29 <samP> tpatil: sure, I will review it again
04:49:30 <tpatil> #link : https://bugs.launchpad.net/masakari/+bug/1746229
04:49:31 <openstack> Launchpad bug 1746229 in masakari "masakari-engine recovery looking for URL endpoint for service_name='Compute Service' instead of 'nova'" [Undecided,New] - Assigned to Louie Kwan (lkwan)
04:49:44 <tpatil> Need to reproduce this bug
04:51:57 <tpatil> samP: I will confirm this LP bug
04:53:09 <samP> tpatil: thanks.
04:56:22 <samP> seems "nova" is correct. but, tpatil: please update
04:56:35 <samP> we only have 4 mins left
04:56:44 <tpatil> samP: ok
04:56:56 <samP> Any updates to share?
04:58:26 <samP> Please use #openstack-masakari @freenode or openstack-dev ML with [masakari] for discuss any issues related to masakari
04:58:58 <samP> Let's finish today's meeting
04:59:04 <samP> Thank you all
04:59:16 <sagara> Thanks
04:59:26 <samP> #endmeeting