Open Stack

This is a reminder of the feedback request.
We are trying to gather feedback until the next policy pop-up meeting (June
7th)
so I'd appreciate your (public or private) inputs !

On Wed, May 11, 2022 at 12:13 AM Takashi Kajinami <tkajinam at redhat.com>
wrote:

> Hello,
>
> tl;dr
> We are looking for some feedback from anyone developing their tool/software
> creating/managing heat stacks, about the new requirement we are
> considering.
>
>
> Recently we've been discussing the issue with Heat and Secure RBAC work[1].
>
> The current target of SRBAC work requires the appropriate scope according
> to the resources.
>  - Project resources like instance, volume or network can be created by
> project-scoped token
>  - Project resources like flavor, user, project or role can be created by
> system-scoped token
>
> This is causing a problem with heat stacks which have both project
> resources
> and system resources, because heat currently uses the single token provided
> by the user in a single stack API call.
>
>
> As part of discussions we have discussed the "split stack" concept, which
> requires
> creating separate stacks per scope. This means If you want to create
> project resources
> and system resources by Heat, you should create two separate heat stacks
> and call
> heat stack api separately using different credentials.
>
> While we still need to investigate the feasibility of this option (eg. how
> smooth we can
> make the migration), we'd like to hear any feedback about the impact of
> the "split stack" concept
> on any external toolings depending on Heat, because this would require
> some workflow/architecture
> change in the toolings. If we hear many negative feedback/concerns then we
> would examine
> different approaches.
>
> Thank you,
> Takashi
>
> [1]
> https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220524/6a39eea6/attachment.htm>