Open Stack

On Wed, 2022-06-08 at 07:19 -0700, Julia Kreger wrote:
> Is that Nova's interpretation, specifically the delineation that
> non-project owned should only be viewable by system, or was system
> scope changed at some point?
> 
no its not just the nova interpreation. there was some differnt view in differnt porjects but
we did an openstack wide reset on this in yoga and on the defintions of the personas
when it became apprent we coudl not proceed with the previous approch.

>  I interpreted it differently, but haven't
> circled back recently. I guess interpretation and evolution in
> specific pockets after initial implementation work started ultimately
> resulted in different perceptions.
> 
> I'll make sure operators are aware there may be significant nuances
> and perception differences since they are using their own etherpads
> and their own communications flow. i.e. we're unlikely to see many
> find/use our own etherpads as they have their own. And yes, this is a
> problem, but it is a higher level community/communications feedback
> issue under active discussion.
well it was under active discussion for a few cycle both at the ptgs and mailing lists, and common understaind was codeified as
part of a comunity wide goal https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
with pahses agree to be implemnted across all project based on the updated common understanding of the personas and definitons
to ensure that seperate interpreation and perspective nolonger differed.

the direction change and rational are documend in the goal document
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change

with the high level roadmap cpature in teh pahse 1,2 and 3 defintions.

but in general we woudl like to get feedback from operatros if what is being propsoed in that document is useful.
As dan noted the scope enforcment aspect is proving a challange for higher level porject like heat and tacker to support.
the is more agreement on the usfullnes of a standard reader role, service role and perhaps manager role as thos standarised
role dont really break exising usage but scope enforcement is a big change.

so the dicusion of RBAC is not finalised but a direction has been chosen and there is a certin amount of moment behind it now.
parts of the design can still change an evlonve but other parts are more concrate like the reader role.
> 
> Granted, I get that the system scope ideas were breaking for some
> projects in specific use patterns since not everything would be the
> same nor possible (which is actually a good thing, context of use and
> all), but it was in theory perfect for a lot of the external audit
> tooling use cases which arise in so many different ways.
> 
> Anyway, off to the next $thing with my scattered brain.
> 
> On Wed, Jun 8, 2022 at 6:53 AM Dan Smith <dms at danplanet.com> wrote:
> > 
> > > the system level of scope does not allow you to see everything across the system
> > > it only allows you to see the non project related resouces
> > > 
> > > so you can see the flavors and host aggreates but not the instances as instances are project scoped.
> > > and project scoped resouces like ports, instances, images and volumes cannot be accessed with a system scope
> > > token if you enabel scope enforcement.
> > > 
> > > that is one of the things we want to get clarity on form operators.
> > > is the disticntion between system level resouces and project level resouces useful.
> > 
> > Yep, exactly this. Given the amount of breakage it brings for things
> > like Heat and Tacker, as well as the potential workflow annoyance for
> > human admins, I really want to measure whether any operators see a
> > benefit here. The persona roles, things like a standardized service
> > role, and getting out of this current situation of having two sets of
> > defaults are priorities for me.
> > 
> > --Dan
>