15:01:28 <amotoki> #startmeeting horizon
15:01:29 <openstack> Meeting started Wed Apr 15 15:01:28 2020 UTC and is due to finish in 60 minutes.  The chair is amotoki. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:33 <openstack> The meeting name has been set to 'horizon'
15:01:42 <Nizars> Hi!
15:01:43 <amotoki> hi
15:01:44 <vishalmanchanda> hi
15:01:49 <Andreas681> Hello
15:01:51 <e0ne> hi
15:01:55 <jberg-dev> greetings!
15:02:15 <rdopiera> aloha
15:02:50 <amotoki> we have enough folks here :)
15:02:52 <amotoki> let's start
15:03:00 <amotoki> #topic annoucements/notices
15:03:26 <amotoki> the last week was the week of feature freeze for cycle-with-rc projects
15:03:27 <Nizars> I would like to discuss a Horizon plugin project that me and Andreas682, jberg-dev, and two other people are working on when the floor is open. :)
15:03:55 <amotoki> we switched cycle-with-intermediary in this cycle, so I am planning to cut a release this week and considering it as the feature freeze
15:04:20 <amotoki> let's discuss potential reviews in the upcoming topic just after this.
15:05:05 <amotoki> Nizars: can we discuss your topic in "On-demand agenda" section later in this meeting?
15:05:50 <Nizars> absolutely, we are new to the format here so we will just follow your lead.
15:06:14 <e0ne> amotoki: does it mean the master will be open fro V release next week?
15:06:33 <e0ne> s/fro/sor
15:06:37 <e0ne> *for
15:07:00 <amotoki> e0ne: next week or later this week. I will let you (all cores) once I cut a release.
15:07:12 <e0ne> amotoki: thanks
15:07:50 <amotoki> Nizars: FYI the meeting format is found at https://wiki.openstack.org/wiki/Meetings/Horizon which redirects you to https://etherpad.opendev.org/p/horizon-release-priorities
15:08:12 <Nizars> Thank you!
15:08:20 <amotoki> another announcement I would like to share is we releases several xstatic modules https://review.opendev.org/#/c/718593/
15:08:57 <amotoki> I will send a governance follow-up patch  to drop 'deprecation' mark in projects.yaml.
15:09:23 <amotoki> e0ne: any notices around the virtual PTG for Victoria?
15:10:00 <e0ne> amotoki: not yet. we need to start planing but I didn't do anything related yet
15:10:12 <amotoki> e0ne: np
15:10:18 <amotoki> FYI: there is an official announment of the virtual PTG http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.html
15:10:42 <amotoki> several teams have started to coordinate meeting slots or some.
15:10:51 <amotoki> this email is worth checking.
15:11:25 <amotoki> anything other to share?
15:12:07 <amotoki> moving on
15:12:25 <amotoki> #topic reviews for Ussuri
15:12:52 <amotoki> I would like to discuss pending review candidates for Ussuri here
15:13:30 <amotoki> https://review.opendev.org/719777 a workaorund with pyscss 1.3.5 or later has landed. thanks e0ne
15:13:59 <amotoki> next one is https://review.opendev.org/709025
15:14:00 <e0ne> amotoki: thanks for the tests!
15:14:31 <amotoki> we can release without regression :)
15:14:46 <amotoki> 709025 is "Add support for multiple swift storage policies"
15:15:03 <amotoki> the code itself is generally good, but I have two questions
15:15:44 <amotoki> the one is display_name. per reply from the author, it looks like not swift limiration but a topic specific to some deployment/public clouds
15:16:07 <amotoki> I am okay with this proposal but I would like to clarify the background for future maintenance.
15:16:58 <amotoki> the other is an immediate value in SCSS https://review.opendev.org/#/c/709025/9/openstack_dashboard/dashboards/project/static/dashboard/project/containers/_containers.scss@116
15:17:09 <amotoki> I would like to avoid this kind of magic number.
15:17:24 <e0ne> amotoki: I missed it:( +1 for your comment for scss
15:17:25 <amotoki> your opinions and feedbacks would be appreciated.
15:18:57 <amotoki> next one is https://review.opendev.org/#/c/708069/
15:19:07 <amotoki> "Refactor error messages" from vishalmanchanda
15:19:21 <amotoki> I tested the proposed code and it looks not ready for ussuri
15:19:30 <vishalmanchanda> yeah:(.
15:19:50 <amotoki> as of now, it does not support 'redirect' in exceptions.handle, so my vote is to defer it to the next cycle
15:21:41 <amotoki> these are possible feature reviews in my mind.
15:22:56 <amotoki> If the first one lands soon, I will include it in the upcoming release. If it takes time, we can skip it.
15:23:31 <amotoki> any other reviews for Ussuri?
15:23:51 <e0ne> nothing from me
15:24:23 <amotoki> note: fixes and test code refactoring changes can land any time
15:25:07 <amotoki> #topic general priorities
15:25:22 <amotoki> I think we can skip this topic and community goals this week.
15:26:12 <e0ne> +
15:26:26 <amotoki> moving on
15:26:27 <amotoki> #topic on-demand agenda
15:26:46 <amotoki> we have a topic here this week
15:26:50 <amotoki> Nizars: go ahead
15:26:55 <Nizars> Thank you
15:27:34 <Nizars> We are working on a Horizon plugin for role based access management through keystone and oslo.policy
15:28:09 <Nizars> The blueprint for the project can be found here
15:28:11 <Nizars> https://blueprints.launchpad.net/horizon/+spec/policies-plugin
15:28:29 <Nizars> The code currently resides on github.
15:28:44 <Nizars> https://github.com/nizos/horizon-policies-plugin
15:28:58 <Nizars> The wiki for the project can also be found here
15:29:00 <Nizars> https://wiki.nordix.org/display/RE/OpenStack+Policies
15:29:41 <Nizars> To my question. How can we get the project approved and how do we move the code to gerrit and start working on it from there?
15:31:33 <amotoki> there are several options to get the feature upstreamed.
15:31:47 <amotoki> the one is to include it in the horizon repo if it fits
15:32:03 <amotoki> another way is to have a separate repository for the feature
15:32:23 <rdopiera> I thought we were moving away from in-repo plugins in the long term?
15:32:33 <amotoki> in case of using a separate repository, there are two choices: an official openstack repo or third-party repo
15:33:16 <Nizars> We would like to move it to an official openstack repo
15:33:31 <Nizars> But it is not a requirement
15:34:12 <amotoki> my question is how policies are maintained.
15:34:28 <amotoki> as of now, keystone does not provide an API to expose policies.
15:34:28 <Nizars> Can you elaborate
15:34:36 <Nizars> That is true
15:34:51 <Nizars> We are planning of creating the backend functionalities ourselves.
15:35:18 <Nizars> We are currently retrieving them through oslo.policy
15:35:46 <amotoki> Nizars: how are they retrieved via oslo.policy?
15:35:54 <Nizars> 1 sec
15:37:05 <amotoki> the default polices are defined in code of individual projects, so doesn't it mean you need to import all projects?
15:37:26 <Nizars> `generator._generate_policy("keystone", self.FILE_PATH)`
15:37:47 <Nizars> we import it as such: `from oslo_policy import generator`
15:38:06 <Nizars> the file path is where it outputs the effective policies
15:38:20 <amotoki> what about default policies?
15:38:37 <Nizars> They are retrieved through the same function
15:39:08 <amotoki> for example, if you would like to load policies from keystone, keystone needs to be installed.
15:39:09 <amotoki> right?
15:39:20 <Nizars> It gets the defaults, then checks the policy files, from there it merges them after that
15:39:42 <Nizars> https://github.com/nizos/horizon-policies-plugin/blob/c9a157254fb4efe62ce2179c12f43e2cab4b005c/policies-plugin/policies_plugin/api/rest/policy_client.py
15:40:05 <Nizars> This is how the output looks like:
15:40:06 <Nizars> https://github.com/nizos/horizon-policies-plugin/blob/c9a157254fb4efe62ce2179c12f43e2cab4b005c/policies-plugin/policies_plugin/api/rest/policy_output.txt
15:40:36 <Nizars> The first line is a policy provided from the policy.json file.
15:40:42 <Nizars> `"identity:get_consumer": "role:admin and system_scope:all"`
15:41:04 <Nizars> In any case. This process is too heavy. There is a lot that is lacking.
15:41:05 <bnemec> That would be one concern. You could only use this tool if the service is installed on the same system as Horizon.
15:41:24 <Nizars> Can you elaborate on that?
15:41:26 <bnemec> It also needs to not be running in a container that doesn't have access to the other service policy files.
15:41:37 <amotoki> bnemec: yeah, my concern is exactly same
15:42:21 <bnemec> Nizars: If keystone is installed standalone (or just not on the same box as horizon), you won't be able to read its policy files.
15:42:24 <Nizars> Help us understand the problem a little better so we can look into it and see if some modifications can be made.
15:42:31 <Nizars> ok
15:42:52 <Nizars> That's a good point.
15:43:35 <amotoki> the original question is how to move the proposal forward.
15:44:02 <Nizars> Can this be dealt with using some config files? Can you think of a way to go about using the plugin in such a use case?
15:44:15 <amotoki> from what I understand so far here, the backend would require to have various service project installed in a same system.
15:44:32 <amotoki> the frontend can consume the backend API.
15:44:42 <amotoki> the backend requirements would be totally different from horizon
15:45:00 <amotoki> so a separate repository would be fine
15:45:13 <Nizars> I see
15:45:13 <amotoki> agree?
15:45:17 <Nizars> Yeah
15:45:59 <amotoki> the second question is what project team is appropriate to cover this project.
15:46:16 <Nizars> I would like to hear your thoughts on what implementation possibilities are there to use the plugin when the services are run in different systems if possible.
15:46:22 <amotoki> I am not sure which project fits this....
15:46:37 <Nizars> installed*
15:47:19 <amotoki> Nizars: is "the plugin" you mention a horizon plugin?
15:47:25 <Nizars> yes
15:48:11 <Nizars> This is how it looks right now when installed in Horizon:
15:48:14 <Nizars> https://imgur.com/TMxrv9d
15:48:29 <amotoki> for the frondend, it can be a horizon plugin
15:48:45 <amotoki> but I am not sure the backend should be run as part of horizon server side.
15:48:54 <Nizars> I see.
15:48:56 <amotoki> it requires too much dependencies
15:49:26 <Nizars> Can you elaborate on that point a little bit more if possible?
15:49:36 <amotoki> okay
15:49:44 <amotoki> we usually use separate repositories for service, client lib and frontend.
15:49:46 <Nizars> Thank you
15:49:58 <amotoki> for example, nova, novaclient and UI (horizon)
15:50:17 <amotoki> this is because they have different dependencies.
15:50:57 <amotoki> this is a discussion on the strategy for repositories (i.e. deliveables),
15:51:02 <amotoki> s/,/./
15:51:16 <amotoki> we also need to consider which project team can host it.
15:51:22 <Nizars> I see
15:52:40 <amotoki> consider its GUI perspective, horizon might be good, but it has other aspects (like a tool to consume/handle policies)
15:53:01 <amotoki> it looks good to discuss it more broadly including TC
15:53:54 <amotoki> Nizars: one more question. Does your team plan to maintain it even after it is upstreaded (i.e. part of OpenStack governance)?
15:53:59 <Nizars> I assume keystone can access policy files of projects installed in different file systems. Is this correct? Is it possible for us to implement something similar to access those files as well? How practical would that be to implement and would it cause any redundancy considering the currently exiting solutions?
15:54:15 <Nizars> I plan on staying active on it.
15:54:21 <Nizars> What does TC stand for?
15:54:30 <amotoki> TC = technical committee
15:54:36 <Nizars> I see, thank you.
15:54:56 <amotoki> regarding the question on keystone above, the answer is no.
15:55:05 <amotoki> keystone only take cares of keystone policies.
15:55:11 <Nizars> I see.
15:55:12 <amotoki> nova take care of nova polices.
15:55:25 <amotoki> oslo.policy provides a common layer to handle policies.
15:56:13 <Nizars> So oslo.policy is able to access the policy files in installations on different systems?
15:56:33 <amotoki> Nizars: no. it can access policies installed locally
15:56:41 <Nizars> I see.
15:56:57 <Nizars> Interesting.
15:57:09 <amotoki> it looks like a discussion on policy loading on the python side. not about GUI.
15:57:22 <Nizars> Yeah
15:57:24 <amotoki> I am afraid it is now not the right place to discuss......
15:57:32 <Nizars> I understand
15:57:40 <Nizars> Thank you for your time and feedback.
15:57:52 <amotoki> I can discuss it as neutron core and a person familiar with oslo.policy. it is not from horizon perspective.....
15:58:42 <amotoki> anyway, my suggestion in this meeting is to raise it to openstack-dsicuss ML (with [tc] tag (technical committees can be aware of it)
15:59:03 <amotoki> in the mail you can explain the concept and purpose of the proposal
15:59:29 <amotoki> (it is better not to discuss it based on the current implementation level)
15:59:44 <amotoki> does it work for you?
16:00:31 <amotoki> we are out of time
16:00:38 <amotoki> thanks for joining all
16:00:39 <Nizars> A simple solution would be to just allow the user to upload the policy files they want to work on themselves and after making the changes they want they can download them and export them themselves but that makes the plugin quite restricted in terms of usefulness. The benefit of the plugin here would have to be editing features and policy checks.
16:00:40 <amotoki> #endmeeting