[all][operator][policy] Operator feedback on 'Consistent and Secure RBAC" (new design for RBAC)

Julia Kreger juliaashleykreger at gmail.com
Thu Jun 9 08:41:09 UTC 2022

On Wed, Jun 8, 2022 at 9:50 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>  ---- On Wed, 08 Jun 2022 09:43:59 -0500 Dan Smith <dms at danplanet.com> wrote ----
>  > Julia Kreger <juliaashleykreger at gmail.com> writes:
>  >
>  > > 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.
>  >
>  > Nope, not a Nova thing. Here's the relevant course correction from two
>  > PTGs ago:
>  >
>  > https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change

Thanks Sean! Now I'm remembering! This is what happens when we
implement things and then change directions and already have some
variety of models. I guess I mentally dropped some of the context due
to this after reading it since it was already "done" and committed
from my perspective. Thanks for the refresher!

>  >
>  > Mohammed is going to be there and primed to discuss this as well. I
>  > think he's pretty well caught up on the current state of things. Having
>  > your experience with what it means in Ironic, as well as his context
>  > from the sticky implementation issues in the other projects should mean
>  > we have pretty good coverage.
> Yes. and it is more than just a single service use case especially when heat discussion[1]
> came up and the scope complexity for heat/NVF users is brought up. We want to make
> sure by introducing scope at the service level which is all good for us does not break
> others users/tooling like heat, tacker, and deployment projects.
> We discussed one solution for heat[2] which is sent on ML for feedback not still now response and that
> is why operators' feedback is critical before we try to implement something that can break them.

Thanks! I think we will try to remember to bring this up, but we also
need to let the operators drive based upon their wants and needs.
Operators tend to want to focus on the nuts and bolts of older
software, so hopefully we will be able to  move the discussion
forward. There is entirely the possibility they just won't want to
discuss it because it is well over the horizon for them.

Semi-on topic, but also on topic to the base different topic: How many
people would be interested in actually trying to meet up with
operators on some semi-regular basis? Having a past operations
background would be a major bonus point because the same words would
be able to be coalesced far faster. Additionally, travel? How far?
etc?  I'm feeling like we need to build a "bridging" group of some
sort. There are a ton of threads I'm on on trying to help bridge some
of these communication gaps right now.

> [1] https://etherpad.opendev.org/p/rbac-zed-ptg#L104
> [2] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028490.html
> -gmann
>  >
>  > Thanks!
>  >
>  > --Dan
>  >
>  >

More information about the openstack-discuss mailing list