15:08:45 <e0ne> #startmeeting horizon
15:08:47 <openstack> Meeting started Wed Nov 25 15:08:45 2020 UTC and is due to finish in 60 minutes.  The chair is e0ne. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:08:50 <openstack> The meeting name has been set to 'horizon'
15:09:06 <vishalmanchanda> hi all
15:09:27 <e0ne> finally, we've started a meeting in a correct channel
15:09:39 <vishalmanchanda> hehe.
15:10:15 <sarmienm> hello, I have some questions, hoping to share them in open discussion
15:10:36 <amotoki> hi
15:10:39 <e0ne> sarmienm: I think we'll have a time for it
15:10:42 <vishalmanchanda> e0ne: Ivan could you please send me the ptg photo if you have?
15:10:44 <e0ne> let's start
15:10:51 <amotoki> I wondered we have a meeting today :p
15:11:18 <e0ne> #topic Notices
15:11:31 <amotoki> sarmienm: it would be nice if you can add your topic to our etherpad https://etherpad.opendev.org/p/horizon-release-priorities (around L.41)
15:11:56 <tmazur> o/
15:12:01 <sarmienm> amotoki: great, will do
15:12:11 <e0ne> #link https://releases.openstack.org/wallaby/schedule.html
15:12:22 <e0ne> we'll reach Wallaby-1 milestone next week
15:12:45 <e0ne> it's not required, but I would like to get horizon release for Wallaby
15:13:21 <e0ne> it's useful cut release early with some removals to get people more time to test it
15:13:38 <vishalmanchanda> e0ne: +1.
15:13:58 <amotoki> sounds good
15:14:40 <e0ne> #topic Horizon Weekly Meeting Time
15:14:55 <e0ne> here is our poll results: #link https://doodle.com/poll/a5eeh6h3v356w8ss
15:15:54 <e0ne> there is no ideal option that fits everybody
15:16:24 <e0ne> there are two preferred options:
15:16:28 <e0ne> a) the current time
15:16:46 <e0ne> b) on hour earlier on thursday
15:17:16 <e0ne> in a current situation I prefer to leave it as is
15:18:23 <amotoki> I am okay with the current meeting time. neutron related meeting no longer conflicts with horizon one.
15:19:01 <amotoki> with option b), I need to skip horizon meeting once a month due to the conflict with OSC/SDK meeting.
15:19:20 <e0ne> #agreed to leave the meeting time as is
15:21:11 <e0ne> #topic Bug deputy report
15:22:48 <amotoki> I see nothing special on incoming bugs this week.
15:23:20 <amotoki> continuing from last week, we have two high priority bugs in victoria.
15:23:23 <e0ne> amotoki: thanks do doing it again
15:24:00 <amotoki> I listed them in the etherpad. Once they are backported it would be good to cut a new release for victoria.
15:24:13 <e0ne> amotoki: https://review.opendev.org/c/openstack/horizon/+/763725 I would like to get it merged and do a new release for stable/victoria
15:24:52 <amotoki> e0ne: I think it is nice if https://review.opendev.org/c/openstack/horizon/+/763161 is included too
15:25:20 <amotoki> e0ne: users cannot create a port with a specific IP address without this
15:25:31 <e0ne> amotoki: +1. let's propose a backport once it will be merged
15:26:04 <amotoki> e0ne: thanks. you already +W'ed the last one in master, so it would land in victoria soon.
15:26:11 <e0ne> +1
15:26:38 <e0ne> #link https://review.opendev.org/c/openstack/horizon/+/764204
15:26:49 <e0ne> please, review this patch made by amotoki
15:26:57 <e0ne> it's a "Document bug triaging process"
15:27:26 <e0ne> I didn't review it yet, but I'm going to to it after the meeting
15:28:24 <amotoki> np. I proposed it just before the meeting
15:28:26 <e0ne> this guide with a but deputies activity should work great
15:28:34 <e0ne> together
15:28:40 <vishalmanchanda> amotoki: nice.
15:29:40 <e0ne> as a side effect of this process I would like to mention that we're thinking more about stable releases
15:29:57 <e0ne> it's good for horizon operators and users
15:30:30 <amotoki> perhaps this topic can be renamed to just "Bugs" :)
15:31:07 <e0ne> I'm volunteering to prepare Bug deputy report for the next meeeting
15:31:48 <vishalmanchanda> e0ne: cool.
15:32:27 <tmazur> e0ne: thanks
15:33:00 <tmazur> I would like to ask some attention to this bug: https://bugs.launchpad.net/horizon/+bug/1902821
15:33:02 <openstack> Launchpad bug 1902821 in OpenStack Dashboard (Horizon) "When open a link for the detal of image as 'Open Link in New Tab', the new tab doesn't show the details of image." [Medium,In progress] - Assigned to Tatiana Ovchinnikova (tmazur)
15:33:20 <e0ne> #link https://bugs.launchpad.net/horizon/+bug/1902821
15:33:46 <e0ne> tmazur: thanks for the fix
15:34:06 <amotoki> Looking through comments, vishalmanchanda and tmazur have different results in their reproduction of this.
15:34:32 <tmazur> It was pretty easy to fix it, thanks e0ne for your review. But it still broken if horizon is deployed say via devstack
15:35:06 <vishalmanchanda> tmazur: your fix looks good to me but I was little confused
15:35:07 <e0ne> I used devserver to verify a fix
15:35:31 <amotoki> tmazur: your fix touches server group detail, but does it fix the image detail page too (as reported in the bug)?
15:35:36 <e0ne> I'll keep my vote until I test it with a apache2
15:35:48 <tmazur> Yes, for some reason the results are different if we using server horizon or the one simply deployed by devstack
15:36:15 <tmazur> My fix is for the part which was broken in both cases
15:36:24 <tmazur> So it has to be merged anyways
15:36:38 <vishalmanchanda> tmazur: yes.
15:36:46 <amotoki> cool
15:37:43 <vishalmanchanda> but we need to check why we get the similar issue for image and key-pair during devstack apache deployment.
15:37:53 <tmazur> I ask for help, 'cause I am really out of ideas :) Apache2 is the same in both cases, debugging leads to the same issue: no default index page
15:38:12 <vishalmanchanda> It would be nice if someone else also check.
15:38:34 <amotoki> thanks. I will check it too w/ and w/o this patch.
15:38:40 <tmazur> And the server groups indeed don't have this default index page, which my fix is about
15:39:43 <tmazur> However key pairs and images have it. But devstack deployment still complains that they don't have it
15:41:05 <tmazur> amotoki: thanks
15:42:28 <e0ne> can we move to the next topic or we've anything more to discuss?
15:42:40 <tmazur> Nothing from my side
15:42:42 <amotoki> nothing from me
15:42:50 <vishalmanchanda> nothing from my side.
15:42:57 <e0ne> #topic victoria translation impact change
15:43:30 <e0ne> #link https://review.opendev.org/c/openstack/horizon/+/758544
15:44:10 <amotoki> I added this one. I noticed one translation string is being dropped in the recent translation import.
15:44:26 <e0ne> It's true
15:44:30 <amotoki> it happens because one string was moved from openstack_dashboard to openstack_auth
15:44:56 <e0ne> I don't remember if there is any policy for such cases once project is released
15:45:02 <amotoki> so a new string appears in openstack_auth and the corresponding one in openstack_dashboard side was dropped.
15:45:44 <e0ne> so I prefer to have a bug fixes especially security-related bug instead of keeping translations
15:45:59 <amotoki> AFAIK there is no policy on this but the heart of the string freeze in the stable policy is not to lose existing translations after releases.
15:46:22 <e0ne> fair enough
15:46:35 <amotoki> one idea is just to recover the corresponding string in openstack_dashboard side (even though it is NOT used actually)
15:48:11 <amotoki> e0ne: what is your comment "fair enough" about? the heart of the string freeze or my idea?
15:48:30 <e0ne> it was about "he string freeze in the stable policy is not to lose existing translations after releases"
15:48:46 <amotoki> okay
15:48:49 <e0ne> *the string freeze
15:50:16 <amotoki> if we choose a route to drop the translated string and let translators translate it again, my vote is to merge translation import after the next victoria release.
15:51:01 <e0ne> is it hard to move translations into the new location?
15:51:20 <e0ne> I didn't contribute to translations, so I don't know
15:51:33 <amotoki> AFAIK only zanata admin can do it but it is totally a manual process.
15:52:59 <e0ne> :(
15:53:28 <amotoki> okay, let's discuss a solution in the horizon channel.
15:53:37 <amotoki> we have one more topic to discuss today.
15:54:26 <e0ne> ok
15:54:29 <e0ne> #topic object storage improvement questions
15:54:51 <e0ne> sarmienm: is it your topic?
15:55:01 <sarmienm> hi, so our plan is to do development on direct uploads of large objects to object storage. basically improve upload, download and deletion and segment handling in horizon
15:55:13 <sarmienm> We wanted to get your suggestions/feedback on how we can go about contributing these changes to a future release once we successfully implement them
15:55:49 <e0ne> it's a good feature to hav
15:55:51 <e0ne> to have
15:56:15 <e0ne> sarmienm: did you read our contributor documentation?
15:56:16 <e0ne> #link https://docs.openstack.org/horizon/latest/contributor/index.html
15:57:50 <amotoki> I would suggest to file a blueprint (or a wishlist bug) to track the effort.
15:58:13 <sarmienm> e0ne: not yet, we wanted to first see if it's possible do development with the goal of contributing it to the public and not just do a fork of the project
15:59:06 <sarmienm> amotoki: ok, thanks we can start with that
15:59:23 <e0ne> sarmienm: here is some documentation how to do it https://docs.openstack.org/horizon/latest/contributor/contributing.html#new-feature-planning
15:59:43 <amotoki> sarmienm: we are always welcome for new features/improvements for areas which horizon covers.
16:00:36 <sarmienm> sounds good thank you
16:01:36 <e0ne> sarmienm: I hope to see your contributions soon. feel free to ask for a help in #openstack-horizon channel
16:02:01 <e0ne> we're out of time. let's move to our channel to continue the discussion
16:02:24 <e0ne> #endmeeting