<div dir="ltr"><div>This is a reminder of the feedback request.</div><div>We are trying to gather feedback until the next policy pop-up meeting (June 7th)<br></div><div>so I'd appreciate your (public or private) inputs  !<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 11, 2022 at 12:13 AM Takashi Kajinami <<a href="mailto:tkajinam@redhat.com">tkajinam@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>tl;dr</div>We are looking for some feedback from anyone developing their tool/software<div>creating/managing heat stacks, about the new requirement we are considering. <br></div><div><br></div><div><br></div><div>Recently we've been discussing the issue with Heat and Secure RBAC work[1].</div><div><br></div><div>The current target of SRBAC work requires the appropriate scope according</div><div>to the resources.</div> - Project resources like instance, volume or network can be created by project-scoped token<div> - Project resources like flavor, user, project or role can be created by system-scoped token</div><div><br></div><div>This is causing a problem with heat stacks which have both project resources</div><div>and system resources, because heat currently uses the single token provided</div><div>by the user in a single stack API call.<br></div><div><br></div><div><br></div><div>As part of discussions we have discussed the "split stack" concept, which requires</div><div>creating separate stacks per scope. This means If you want to create project resources</div><div>and system resources by Heat, you should create two separate heat stacks and call</div><div>heat stack api separately using different credentials.<br></div><div><br></div><div><div>While we still need to investigate the feasibility of this option (eg. how smooth we can</div><div>make the migration), we'd like to hear any feedback about the impact of the "split stack" concept</div><div>on any external toolings depending on Heat, because this would require some workflow/architecture<br></div><div>change in the toolings. If we hear many negative feedback/concerns then we would examine</div><div>different approaches.<br></div></div><div><br></div><div>Thank you,</div><div>Takashi</div><div><br></div><div><div>[1] <a href="https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html" target="_blank">https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html</a></div><div><br><br></div></div></div>
</blockquote></div>