15:03:30 <e0ne> #startmeeting horizon
15:03:31 <openstack> Meeting started Wed Jan 27 15:03:30 2021 UTC and is due to finish in 60 minutes.  The chair is e0ne. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:34 <openstack> The meeting name has been set to 'horizon'
15:04:24 <vishalmanchanda> hi  all
15:04:27 <tmazur> o/
15:04:30 <rdopiera> o/
15:05:02 <amotoki> hi
15:05:18 <ikanias> hi
15:06:27 <e0ne> looks like we can start
15:07:13 <e0ne> #topic Notices
15:07:56 <e0ne> #link https://releases.openstack.org/wallaby/schedule.html
15:08:25 <e0ne> just a kindly reminder that  we've got about 1.5 months until feature freeze
15:09:36 <e0ne> that's all updates from my side this week
15:10:36 <amotoki> I have three topics to share but they are kind of progres reports, so I am not sure this is the right topic.
15:10:59 <e0ne> #chair amotoki
15:11:00 <openstack> Current chairs: amotoki e0ne
15:11:13 <e0ne> amotoki: feel free to change a topic:)
15:11:15 <e0ne> unfortunately, I wasn't very active in community during last weeks. I hope, I'll increase my activities soon
15:11:21 <amotoki> enriquetaso: thanks
15:11:40 <e0ne> btw, here is our etherpad with topics to discuss: https://etherpad.opendev.org/p/horizon-release-priorities
15:12:10 <amotoki> yeah, I forgot to add them this week :(
15:12:55 <amotoki> does anyone have other topics to discuss? I think we can cover one by one. my topics are expected to be short.
15:13:21 <amotoki> rdopiera: for example, would you like to continue the policy stuff?
15:13:42 <rdopiera> amotoki: we are still thinking about how to handle that
15:13:52 <amotoki> rdopiera: okay.
15:14:02 <amotoki> let me cover my topics first
15:14:15 <amotoki> #topic merge tempest-horizon into horizon
15:14:38 <amotoki> gmann and I worked on the merge of tempest-horizon into horizon last week and we had good progress.
15:14:45 <amotoki> https://review.opendev.org/q/topic:%22merge-horizon-test%22+(status:open%20OR%20status:merged)
15:15:05 <amotoki> the test in temepst-horizon has been merged into tempest.
15:15:22 <e0ne> cool
15:15:28 <amotoki> I proposed horizon side patches which consume tempest in our gate instead of tempest-hroizon
15:16:12 <amotoki> we need to update zuul job configuration from stein to master.
15:16:31 <ikanias> can i ask something?
15:16:37 <rdopiera> when you set this topic for a moment I thought you were merging it back into the horizon repository, not the tempest repository
15:16:39 <ikanias> regarding this
15:16:47 <amotoki> rocky and earilier already use specific version of tempest.
15:16:53 <amotoki> ikanias: go ahead
15:17:16 <ikanias> we just got the horizon-tempest test to downstream
15:17:25 <ikanias> do we need to change anything now?
15:17:27 <amotoki> rdopiera: sorry. into "tempest" ....
15:17:59 <amotoki> ikanias: just a moment. i will check the new test name.
15:18:15 <ikanias> ok
15:19:10 <amotoki> the new test name is tempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps
15:19:23 <ikanias> thanks
15:19:47 <amotoki> and you may need to set horizon = true in tempest.conf https://zuul.opendev.org/t/openstack/build/6865f69c8b6b475a9fec054b93260ce9/log/controller/logs/tempest_conf.txt#105
15:19:56 <amotoki> I am not sure we set it before.
15:20:13 <ikanias> ok i will do that. thanks a lot
15:20:31 <amotoki> ikanias: feel free to ask me or #-qa if you have questions on this migration.
15:21:01 <ikanias> cool
15:21:40 <amotoki> moving on
15:21:47 <amotoki> #topic jquery upgrade
15:22:30 <amotoki> as discussed in the last meeting we updated the min version of xstatic-jquery to 1.12.x https://review.opendev.org/c/openstack/horizon/+/771577
15:22:46 <amotoki> and xstatic-jquery-migrate upgrade patch was merged
15:23:17 <amotoki> the release patch is under review https://review.opendev.org/c/openstack/releases/+/771712
15:23:45 <amotoki> e0ne: hopefully you can put +1 to this patch. double ack from ptl and release liaison would be nice.
15:23:55 <rdopiera> do you know who else can +2 this?
15:24:16 <amotoki> the release mngment team can +2
15:24:52 <e0ne> amotoki: sure, +1'ed
15:25:42 <amotoki> perhaps we can ping hberaud
15:26:11 <amotoki> that's the update from my side
15:26:18 <amotoki> on this topic
15:26:25 <e0ne> smcginnis: could you please take a look on  https://review.opendev.org/c/openstack/releases/+/771712 once you have a time>
15:26:27 <e0ne> ?
15:28:55 <amotoki> can we move on?
15:29:59 <e0ne> yes
15:30:00 <amotoki> okay, let's move to the next topic
15:30:03 <amotoki> #topic renaming Chinese locales
15:30:52 <amotoki> we discussed renaming Chinese locales in the PTG. I discussed a plan with Ian and Andreas.
15:31:29 <amotoki> It looks like we have a consensus on renaming django related locales to the new locales (zh_Hans/Hant)
15:31:41 <amotoki> and I am preparing an email on this.
15:32:03 <amotoki> The current plan is to handle it in the translation script.
15:32:52 <e0ne> amotoki: will we rename locales in the documentation too?
15:33:12 <amotoki> e0ne: at the moment, locales in docs will be kept as-is.
15:33:18 <e0ne> ok
15:33:26 <amotoki> it is because we have docs in other repos like nova
15:33:33 <e0ne> I hope, it won't confuse users and operators
15:34:13 <amotoki> yeah, it was rainsed in the internal discussion.
15:34:34 <amotoki> we cannot avoid some level of confusions.
15:35:07 <amotoki> zh-CN/TW for doc and zh-Hans/Hant for django apps leads to confusion for hroizon (and horizon plugin) developers.
15:35:28 <amotoki> but we can avoid confusions in documentation readers and translators.
15:35:52 <e0ne> fair enough
15:35:55 <amotoki> so atm I think it is a good compromise.
15:36:08 <e0ne> will with renaming be applied for plugins too?
15:36:18 <amotoki> yes
15:36:30 <amotoki> I am planing to handle renaming in the infra script
15:36:44 <amotoki> so that we can propose a migration patch at once
15:36:54 <e0ne> in a such case, it sounds good to me
15:39:03 <amotoki> that's my current plan. anyway I will send a plan to the list.
15:39:33 <amotoki> that's all three topics from me.
15:41:18 <e0ne> amotoki: thanks for raising these topics
15:42:11 <amotoki> yw
15:42:26 <amotoki> #topic Open Discussions
15:42:26 <e0ne> do we have anything more to discuss today?
15:43:29 <vishalmanchanda> nothing much from my side.
15:43:40 <amotoki> rdopiera: regarding the policy stuff, you mentioned you are focusing on "reader" role last week.
15:43:54 <amotoki> but I am not sure how we can supportr the system reader without the system scope.
15:44:15 <amotoki> I wonder what is your rough thought.
15:44:23 <rdopiera> amotoki: same way we support admin currently
15:44:54 <rdopiera> the main question for us is to figure out when to consider the user an admin and when not
15:45:14 <rdopiera> right now we just look at the hardcoded role name
15:45:47 <rdopiera> which won't work with the new "readonly_admin" role, or whatever they call it
15:46:46 <amotoki> ah... I thought "role:reader and project_id:%(project_id)" (project reader) and "role:reader and system_scope:all" (system reader).
15:47:02 <amotoki> so perhaps it might be a bit different issue
15:47:08 <rdopiera> so we want two read-only roles, user and admin
15:47:22 <rdopiera> the read-only user pretty much works in horizon already
15:47:40 <rdopiera> you just make a custom role, and you see most views, just without the action buttons
15:48:33 <amotoki> my understanding is same. read-only user should work
15:49:01 <amotoki> (there might be a few exceptions though...)
15:49:45 <rdopiera> the firs issue we identified with a read-only admin is that right now there is only one role name hardcoded to act as admin, and any other role, with a different name, will not act the same way, even if it has the same policies
15:50:32 <rdopiera> for some views we can solve this by checking for a specific policy, like the permission to edit flavors, instead of checking if the user is an admin
15:50:46 <rdopiera> but for other views, like admin/instances, that doesn't work
15:51:22 <amotoki> openstack_auth/utils.py get_admin_roles() should work but perhaps cleanups in the past were not enough.
15:52:34 <rdopiera> oh, I see there is simply a setting for this, OPENSTACK_KEYSTONE_ADMIN_ROLES
15:52:42 <rdopiera> I was thinking about solving it this way
15:52:49 <rdopiera> that makes things easier
15:52:58 <rdopiera> we just need to update the checks on the panels then
15:53:06 <amotoki> I might be missing something as OPENSTACK_KEYSTONE_ADMIN_ROLES was introducd before we implemented RBAC support in horizon....
15:53:18 <rdopiera> but the problem you are concerned about seems to be something different?
15:54:24 <rdopiera> amotoki: can you elaborate on the system scope token problem? I've heard about it several times in passing, but I never understood what the issue is exactly
15:55:05 <rdopiera> I know that we are automatically promoting the user scope token to system scope in horizon sometimes, but I'm not sure why this is a problem
15:56:06 <amotoki> I see two problems at least.
15:56:13 <amotoki> the one is when we should use the system scoped token.
15:56:49 <amotoki> when the admin role and the system scoped token are mixedly used, how and when should we swtich tokens?
15:56:56 * rdopiera thinks in the admin/* panels
15:57:21 <amotoki> but not all projects support the system scoped token
15:57:27 <amotoki> how can we handle th emixed case?
15:57:56 <rdopiera> the api/* files will know, depending on the service?
15:58:34 <amotoki> it is a possible option
15:58:40 <rdopiera> or do you mean "projects" as in tenants?
15:59:07 <amotoki> no, I mean back-end service projects like nova.
15:59:29 <rdopiera> so for me that's obvious, the api lib should know which token to use
16:00:07 <rdopiera> but I see it can get messy quick
16:00:24 <rdopiera> I hope we won't need to touch it in this case, but if we do, we will bring it up
16:00:50 <rdopiera> thanks for the explanation
16:01:16 <amotoki> thanks.
16:01:51 <e0ne> we're out of time. let's move to #openstack-horizon channel
16:01:59 <amotoki> rdopiera: I understand your main problem is htat horizon does not handle multple admin-ness roles properly (admin and readonly-admin) :)
16:02:02 <e0ne> thanks everybody for your contributions
16:02:10 <e0ne> #endmeeting