Open Stack

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? 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.

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