| *** hemna9 is now known as hemna | 07:37 | |
| abhishekk | #startmeeting glance | 14:00 |
|---|---|---|
| opendevmeet | Meeting started Thu Dec 16 14:00:06 2021 UTC and is due to finish in 60 minutes. The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'glance' | 14:00 |
| abhishekk | #topic roll call | 14:00 |
| abhishekk | #link https://etherpad.openstack.org/p/glance-team-meeting-agenda | 14:00 |
| abhishekk | o/ | 14:00 |
| abhishekk | croelandt, looks like, just you and me today | 14:00 |
| abhishekk | and we don't have much in agenda | 14:01 |
| pdeore | I'm also here :) o/ | 14:01 |
| abhishekk | ack | 14:01 |
| abhishekk | lets start and finish this quickly | 14:02 |
| abhishekk | #topic release/periodic jobs update | 14:02 |
| abhishekk | Milestone 2 is 3 weeks away | 14:03 |
| abhishekk | and we are considering SRBAC manager work in this milestone | 14:03 |
| abhishekk | so we need to be ready with expected work by the end of this year | 14:03 |
| croelandt | abhishekk: damn :-( | 14:03 |
| abhishekk | pdeore, ^^ | 14:03 |
| abhishekk | croelandt, AFAIK it is just addition in tempest plugin coverage and no change at glance side | 14:04 |
| pdeore | ack, only glance side work? or tempest tests are also expected in this milestone? | 14:04 |
| abhishekk | pdeore, tempest plugin tests | 14:04 |
| pdeore | ack | 14:04 |
| abhishekk | there is/will not be much glance side work for implementing manager role support | 14:05 |
| pdeore | yes | 14:05 |
| abhishekk | ok, moving ahead | 14:05 |
| abhishekk | Periodic jobs - all green | 14:05 |
| abhishekk | No failure since last 3 weeks so we are good here | 14:06 |
| abhishekk | moving ahead | 14:06 |
| abhishekk | #topic Year end | 14:07 |
| abhishekk | As most of the team will be on leave, No meeting on 23 and 30 December | 14:07 |
| abhishekk | We will be directly meeting on 1st Thursday of a new year | 14:07 |
| abhishekk | I will be around whole time if there is any urgent work/issue arises during this period | 14:08 |
| croelandt | good luck | 14:08 |
| abhishekk | :P | 14:09 |
| abhishekk | That's it from me for today | 14:09 |
| abhishekk | #topic Open discussion | 14:09 |
| abhishekk | anything ?? | 14:10 |
| abhishekk | pdeore, croelandt | 14:10 |
| pdeore | nothing from me too .. | 14:10 |
| abhishekk | Ok then, see you guys in next year | 14:11 |
| abhishekk | happy holidays | 14:11 |
| abhishekk | thank you all | 14:11 |
| croelandt | See you next year! | 14:11 |
| croelandt | and right now in the other channel | 14:11 |
| abhishekk | :P | 14:11 |
| abhishekk | #endmeeting | 14:12 |
| opendevmeet | Meeting ended Thu Dec 16 14:12:06 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:12 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/glance/2021/glance.2021-12-16-14.00.html | 14:12 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/glance/2021/glance.2021-12-16-14.00.txt | 14:12 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/glance/2021/glance.2021-12-16-14.00.log.html | 14:12 |
| gmann | seems meetpad not working, we can have policy popup meeting on IRC here | 18:01 |
| gmann | we might not have much people here nut just checking in case any one has any query | 18:01 |
| gmann | #startmeeting policy | 18:01 |
| opendevmeet | Meeting started Thu Dec 16 18:01:39 2021 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:01 |
| opendevmeet | The meeting name has been set to 'policy' | 18:01 |
| rdopiera | Hi, I just added my point to the agenda on the etherpad | 18:01 |
| gmann | sure checking | 18:02 |
| rdopiera | I can elaborate | 18:02 |
| gmann | sure | 18:03 |
| rdopiera | we started work on the phase two, for the system admin support, in horizon, and for that we added the ability to switch from a project scope to the system scope, and it mostly all works as expected, however, in the system scope we are disallowed to make many calls that are used on a lot of admin pages | 18:04 |
| gmann | yeah, and that is for services right like nova etc? | 18:05 |
| gmann | not just keystone | 18:05 |
| rdopiera | most of the problematic pages are in nova | 18:05 |
| gmann | :) yeah | 18:05 |
| gmann | As per the new schedule keystone system/domain scope policies are ready means their system scope panel in horizon can be implemented | 18:05 |
| rdopiera | what I can tell is that some of the calls we need to make on them are allowed, but some not | 18:05 |
| gmann | and nova is going to modify the policy in Yoga cycle where we are modifying many policy from system to project scoped etc | 18:06 |
| gmann | this is #link BP https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2 | 18:07 |
| rdopiera | I also wanted to clarify how it should work in Horizon from the user interface point of view | 18:07 |
| gmann | yeah that will be very helpful and we can see how user going to use it | 18:07 |
| rdopiera | so far we based our implementation on the PTG discussion, and basically just added an entry to the project scope switching menu, that says "system scope" | 18:07 |
| rdopiera | any use who has access to the system scope has that option, and can switch to this scope, at which point they will only see the menu entries appropriate for that scope | 18:08 |
| rdopiera | any user* | 18:08 |
| gmann | other scope entry will not be visible at all right? | 18:08 |
| rdopiera | you only see the entries in the menu that are allowed by the policy with your current token | 18:09 |
| gmann | +1 | 18:09 |
| rdopiera | I have two doubts about this. | 18:09 |
| rdopiera | First, from the SRBAC high-level descriptions it seems that there is going to be a special, separate user, that has access to the system scope, and has no access to anything else, and that is going to be the only user who has access to the system scope | 18:10 |
| rdopiera | If that is the case, we will need a mechanism that allows users who have no access to any project to log into Horizon -- currently if you try that, horizon will not let you to log in. And then you will start in the system scope right from the beginning -- is that right? | 18:11 |
| gmann | yeah so with the new design we finalized in goal is system and project scope users are very much isolated in term of access control (except few cases where few API will be accessible to both) | 18:12 |
| rdopiera | currently a user who doesn't have a project can't log into horizon | 18:13 |
| gmann | yes that is my expectation. | 18:13 |
| gmann | system users will not have any project_id in their token and can perform only operation allowed to system level which is nothing but the one does not need projetc id like GET hypervisors etc | 18:13 |
| rdopiera | thanks, then I will add an RFE for handling this case | 18:14 |
| gmann | horizon should allow them to login even they are not associated with any project | 18:14 |
| gmann | and once they login to horizon they can switch to other scope if they are allowed by keystone | 18:15 |
| gmann | we are very much separating the system scope users to perform any project level resource operation | 18:15 |
| rdopiera | Second doubt I have, currently a lot of API calls are available by policy both in system scope and in project scope -- so the user has access to the same "admin" and "identity" menus as in system scope -- my question is should we explicitly hide them in horizon with some option, or will that be handled by new and updated set of policies? | 18:15 |
| gmann | yeah, this is good question. | 18:16 |
| gmann | for keystone, I think policy are ready and they will not be changed much, In Yoga cycle release we are hoping operator will use the new policy. so it is safe to migrate them in Horizon also | 18:17 |
| gmann | but for service policy like Nova, cinder etc we are re-modifying the policies in Yoga and they should be ready after Yoga | 18:17 |
| rdopiera | for example, I have a WIP patch for an "ENFORCE_SCOPE" option in horizon that wold hide some menu entries: https://review.opendev.org/c/openstack/horizon/+/818763 | 18:17 |
| gmann | and that time there will be less policy with both scope | 18:17 |
| gmann | for services, I horizon needs to wait until they are ready | 18:18 |
| rdopiera | so we should basically pause work on this? | 18:19 |
| gmann | rdopiera: not pause but do only for keystone panel and for other yes hold until Yoga cycle | 18:20 |
| gmann | Yoga cycle release or whenever services are ready. for example If I can implement for nova in Yoga m-3 or so then you can see but that is still late | 18:21 |
| rdopiera | we use the policies provided to decide which panels to display, we can't use system scope just for some panels | 18:21 |
| gmann | so considering services other than keystone will be good for Z cycle | 18:21 |
| gmann | rdopiera: i mean if you switch for keystone panel and for other services shows everything what it is currently with message that NO SCOPE SWITCH FOR THIS SERVICE YET | 18:22 |
| gmann | does that work? | 18:22 |
| rdopiera | no | 18:22 |
| gmann | ohk | 18:22 |
| rdopiera | the switch is global, like switching projects | 18:23 |
| gmann | i see | 18:23 |
| rdopiera | we can add code to some of the panels that will hide them in system_scope explicitly | 18:24 |
| rdopiera | ignoring the policies | 18:24 |
| gmann | so in global switch, if we say either system or project scope nova panel will be shown same ? | 18:24 |
| gmann | yeah kind of ignoring | 18:24 |
| gmann | ignoring new policy | 18:24 |
| rdopiera | right now you will see anything that the policy allows | 18:25 |
| rdopiera | it's entirely driven by policy checks | 18:25 |
| rdopiera | we can add additional checks, but to do that, we need to know what should be displayed in which scope | 18:25 |
| rdopiera | that patch I linked does something like that | 18:26 |
| rdopiera | it hides the identity panel when not in the syste_scope, when the ENFORCE_SYSTEM_SCOPE option is set | 18:26 |
| gmann | so for say nove panel if we ust ignore the scope switching ? | 18:27 |
| gmann | rdopiera: ohk, so ENFORCE_SYSTEM_SCOPE is global one not per service? | 18:27 |
| rdopiera | I can hide nova panels when you are switched to system scope | 18:27 |
| gmann | ah hide is not good | 18:27 |
| rdopiera | I can make it per service | 18:27 |
| gmann | yeah, beacuse in actual we have enforce_scope per service so that operator can enable/disable per services | 18:28 |
| rdopiera | I can show you how it works on video? | 18:28 |
| rdopiera | I quick meet call? | 18:28 |
| gmann | sure. meetpad not working currently | 18:28 |
| gmann | but google meet ok for me | 18:28 |
| rdopiera | https://meet.google.com/juc-fuho-iic | 18:28 |
| gmann | joining, 1 min | 18:29 |
| gmann | I am adding note in etherpad for discussion on horizon plan. | 18:45 |
| gmann | thanks again rdopiera for joining | 18:45 |
| gmann | we will cancel next meeting which is on 30th Dec and will meet on 13th Jan | 18:46 |
| gmann | #endmeeting | 18:46 |
| opendevmeet | Meeting ended Thu Dec 16 18:46:19 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:46 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/policy/2021/policy.2021-12-16-18.01.html | 18:46 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/policy/2021/policy.2021-12-16-18.01.txt | 18:46 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/policy/2021/policy.2021-12-16-18.01.log.html | 18:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!