15:00:54 <e0ne> #startmeeting horizon
15:00:56 <openstack> Meeting started Wed Jul  1 15:00:54 2020 UTC and is due to finish in 60 minutes.  The chair is e0ne. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:59 <openstack> The meeting name has been set to 'horizon'
15:01:17 <vishalmanchanda> hi
15:01:26 <e0ne> vishalmanchanda: hi
15:01:45 <e0ne> let's wait until more people will join us
15:02:20 <rdopiera> o/
15:02:24 <e0ne> vishalmanchanda: before we start. I was AFK whilte you were discussing cinder messages with amotoki
15:03:26 <e0ne> #topic Notices
15:03:55 <e0ne> actually, I don't have any updates this week
15:04:41 <e0ne> I'm going to setup a poll for our virtual mid-cycle later tonight to clarify what date and time work for us
15:05:06 <vishalmanchanda> +1.
15:05:21 <e0ne> in cinder we did it instead of a regular weekly meeting but it could be pretty late for vishalmanchanda and amotoki
15:06:03 <e0ne> it's supposed to be later this month around Victoria-2 milestone
15:06:04 <vishalmanchanda> e0ne: hmm.. I can manage if it work for everyone.
15:07:20 <amotoki> I missed meeting last two weeks as I was sleepy. I am trying to move my life rhythm earlier, but I got sleepy too early :-(
15:07:56 <amotoki> no intention to skip the meeting
15:09:47 <e0ne> amotokiL that's why I asked at PTG  if a current time works good for everybody
15:10:27 <e0ne> #topic Stable maintenance and EOL
15:10:46 <e0ne> amotoki: you added this topic for PTG but we had no time to discuss it
15:10:51 <e0ne> #linke https://etherpad.opendev.org/p/horizon-v-ptg
15:11:06 <e0ne> I was waiting for all stable cores to discuss it
15:12:01 <e0ne> #link https://etherpad.opendev.org/p/horizon-v-ptg (line #105)
15:12:19 <amotoki> I just wonder who are stakeholders for older branches and whether we have bandwidth to check which stable branches including gate healthiness
15:12:54 <e0ne> personally, I'm not interested in ocata anymore
15:13:12 <e0ne> but I still have customers with pike and queens
15:13:24 <rdopiera> we use queens, stein and train
15:13:43 <e0ne> so I'm OK to mark ocata as EOL (end of life)
15:13:57 <amotoki> ocata is already under discussion for EOL
15:14:29 <amotoki> as it is not easy to maintain its gate related to py27 drop
15:14:40 <e0ne> that's true
15:14:52 <amotoki> as you know ocata will be EOL soon as a whole
15:15:28 <amotoki> it is a different story outside of horizon
15:15:39 <e0ne> +1
15:16:23 <e0ne> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015112.html
15:16:29 <amotoki> rocky and older are now in EM phase. which branches are you interested in?
15:17:03 <amotoki> according to the above comment from e0ne and rdopiera, pike is oldest
15:17:21 <amotoki> and queens has common interest at least from RH and mirantis
15:17:37 <e0ne> unfortunately, I have to support pike(
15:18:08 <amotoki> hehe, it is not so surprising
15:19:32 <amotoki> I think what we need to do are (1) to check gate healthiness in stable branches and then (2) fix gate failures if any
15:19:53 <e0ne> amotoki: I can do it
15:20:07 <amotoki> I believe periodic jobs help us for (1) as it is not easy to check it regularly
15:20:40 <amotoki> (2) is totally up to who can work on it.
15:21:54 <e0ne> #action e0ne to check health of gates fro EM branches
15:22:40 <e0ne> at least, I'll check the current situation and will do the best to fix if gages are broken
15:23:23 <amotoki> I plan to backport https://review.opendev.org/#/c/737686/ to stable branches and then prepare the grafana dashboard at grafana.o.o.
15:23:41 <amotoki> we can check the healiness (for example) in the team meeting.
15:23:51 <e0ne> amotoki: awesome!
15:23:58 <vishalmanchanda> cool.
15:26:33 <e0ne> let's start with this and see how it works during the next meeting
15:27:11 <e0ne> #topic stable review policy
15:29:05 <e0ne> here is general guideline: https://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
15:29:18 <e0ne> we follow it
15:29:45 <e0ne> but it seam reasonable to fit them a bit with a current situation in horizon team
15:30:29 <e0ne> from the etherpad: we previously had a policy to allow a single +2 if a backport is proposed by a stable core to handle the situation with only a couple of stable cores.
15:30:59 <e0ne> I didn't know about this rule before, but lt sounds absolutely reasonable for me
15:31:15 <e0ne> at least for a simple fixes
15:31:29 <amotoki> the comment is from me. It was true when Rob was the PTL
15:32:49 <e0ne> it seams it was introduced before I started contribution to horizon
15:33:22 <amotoki> this rule assumes that stable reviewers are familiar with the stable policy, so stable reviewers are assumed to consider the stable policy when they propose backports.
15:34:03 <amotoki> I beleve the current stable reviewers are familiar with the policy
15:34:12 <e0ne> amotoki: sure. in any case, stable core and put -1 or -2 for any proposed patch
15:35:21 <amotoki> yes, and if a stable core is not sure we can ping another stable core :)
15:35:27 <e0ne> +2
15:35:52 <e0ne> or we can ping openstack stable team
15:36:03 <amotoki> yeah
15:36:21 <e0ne> rdopiera: are you agree with this proposal?
15:36:30 <amotoki> in such case we discuss it in the mailing list. it works in most cases I believe.
15:39:46 <rdopiera> e0ne: I don't like it, but I guess we don't have much choice
15:40:43 <e0ne> rdopiera: It's not ideal solution
15:41:53 <amotoki> or we can always ping second core. we have three active stable cores now, so it can work too.
15:42:00 <amotoki> (as we do now)
15:43:37 <amotoki> I am just afraid what happens if my activity slows down.
15:44:09 <amotoki> I want not be a bottleneck :)
15:47:45 <rdopiera> let's try it, and we can always get back to the old way
15:47:52 <e0ne> we can try to do stable reviews on a weekly basis
15:49:18 <e0ne> what is our agreement on this?
15:50:53 * rdopiera agrees
15:51:15 <amotoki> the original proposal is from me, so I have no objection. If you are okay, we can try a single +2 from bakcports from stable cores.
15:51:31 <amotoki> looks like we agree
15:51:52 <e0ne> #agreed to allow a single +2 if a backport is proposed by a stable core to handle the situation with only a couple of stable cores
15:52:42 <e0ne> we can re-visit our decision in the future if any objection will be
15:53:04 <e0ne> #topic Open Discussion
15:53:16 <amotoki> let's raise if you see any question or issue in IRC or meeting :)
15:53:34 <vishalmanchanda> I want to discuss this cinder messages bp.
15:53:39 <e0ne> we've got seven minutes left
15:53:52 <vishalmanchanda> I have already discuss some points with amotoki and I am almost agrees with him.
15:54:10 <vishalmanchanda> e0ne: I also need your opinion on this as you draft this bp for horizon.
15:54:26 <e0ne> two cores agreed, I don't want to argue :)
15:54:26 <vishalmanchanda> #link https://specs.openstack.org/openstack/cinder-specs/specs/newton/summarymessage.html
15:55:16 <e0ne> vishalmanchanda: FYI, I'm going to add some backup-related messages this cycle
15:55:39 <vishalmanchanda> e0ne: nice.
15:56:39 <vishalmanchanda> e0ne: What's you think how Can we show it in horizon?
15:56:46 <amotoki> as summary, I pointed that messages related to snapshots need to be covered in the volume detail page and whether it fits normal user scenarios.
15:57:35 <amotoki> and if a user have some problem(s) on a snapshot they need to check the volume detail instead of the snapshot detail in the current proposal.
15:58:54 <amotoki> honestly I am not sure we need to cover all messages related to a specific volume including snapshots (and potentially backups) in the volume detail.
15:59:17 <amotoki> so it leads to my question on user scenarios.
16:00:30 <e0ne> it's a good question
16:00:37 <e0ne> I need to think a bit
16:00:42 <e0ne> we're out of time
16:01:17 <e0ne> let's continue discussion in the  #openstack-horizon channel
16:01:20 <e0ne> #endmeeting