<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>See below.</div>
<div><br>
</div>
<div>On Thu, 2017-05-25 at 15:49 -0500, Lance Bragstad wrote:</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, May 25, 2017 at 2:36 PM, Marc Heckmann <span dir="ltr">
<<a href="mailto:marc.heckmann@ubisoft.com" target="_blank">marc.heckmann@ubisoft.com</a>></span> wrote:<br>
<blockquote type="cite">
<div>
<div>First of all @Lance, thanks for taking the time to write and summarize this for us. It's much appreciated.</div>
</div>
<br>
</blockquote>
<div><br>
</div>
<div>Absolutely! it helps me think about it, too.</div>
<div> </div>
<blockquote type="cite">
<div>
<div></div>
<div><br>
</div>
<div>While I'm not aware of all the nuances, based on my own testing, I feel that we are really close with option 1.</div>
<div><br>
</div>
<div>That being said, as you already stated, option 2 is clearly more inline with the idea of having a "global" Cloud Admin role. So long term, #2 is more desirable.</div>
<div><br>
</div>
<div>Given the two sentences above, I certainly would prefer option 3 so that we can have a usable solution quickly. I certainly will continue to test and provide feedback for the option 1 part.
</div>
<div><br>
</div>
</div>
<br>
</blockquote>
<div><br>
</div>
<div>It sounds like eventually migrating everything from the is_admin_project to true global roles is a migration you're willing to make. This might be a loaded question and it will vary across deployments, but how long would you expect that migration to take
for you're specific deployment(s)?</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Maybe I'm over-simplifying, but if properly documented I would expect there to be a cut-over release at some point where we would need to switchover and create the proper globally scoped role(s). I guess we could live with is_admin_project for 2-3 releases
in the interim. </div>
<div><br>
</div>
<div>-m</div>
<div></div>
<div><br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote type="cite">
<div>
<div></div>
<div>-m</div>
<div>
<div class="h5">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On Thu, 2017-05-25 at 10:42 +1200, Adrian Turjak wrote:</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<p><br>
</p>
<br>
<div class="m_1894739903435420746moz-cite-prefix">On 25/05/17 07:47, Lance Bragstad wrote:<br>
<snip></div>
<blockquote type="cite">
<div dir="ltr"><b>Option 2</b>
<div><br>
</div>
<div>Implement global role assignments in keystone.</div>
<div><i><br>
</i></div>
<div><i>How it works:</i></div>
<div><i><br>
</i></div>
<div>Role assignments in keystone can be scoped to global context. Users can then ask for a globally scoped token </div>
<div><br>
</div>
<div>Pros:</div>
<div>- This approach represents a more accurate long term vision for role assignments (at least how we understand it today)</div>
<div>- Operators can create global roles and assign them as needed after the upgrade to give proper global scope to their users</div>
<div>- It's easier to explain global scope using global role assignments instead of a special project</div>
<div>- token.is_global = True and token.role = 'reader' is easier to understand than token.is_admin_project = True and token.role = 'reader'</div>
<div>- A global token can't be associated to a project, making it harder for operations that require a project to consume a global token (i.e. I shouldn't be able to launch an instance with a globally scoped token)</div>
<div><br>
</div>
<div>Cons:</div>
<div>- We need to start from scratch implementing global scope in keystone, steps for this are detailed in the spec</div>
<div><br>
</div>
</div>
</blockquote>
<snip><br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <span dir="ltr">
<<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></span> wrote:<br>
<blockquote type="cite">
<div dir="ltr">Hey all,
<div><br>
</div>
<div>To date we have two proposed solutions for tackling the admin-ness issue we have across the services. One builds on the existing scope concepts by scoping to an admin project [0]. The other introduces global role assignments [1] as a way to denote elevated
privileges.</div>
<div><br>
</div>
<div>I'd like to get some feedback from operators, as well as developers from other projects, on each approach. Since work is required in keystone, it would be good to get consensus before spec freeze (June 9th). If you have specific questions on either approach,
feel free to ping me or drop by the weekly policy meeting [2].<br>
</div>
<div><br>
</div>
<div>Thanks!<br>
</div>
</div>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
Please option 2. The concept of being an "admin" while you are only scoped to a project is stupid when that admin role gives you super user power yet you only have it when scoped to just that project. That concept never really made sense. Global scope makes
so much more sense when that is the power the role gives.<br>
<br>
At same time, it kind of would be nice to make scope actually matter. As admin you have a role on Project X, yet you can now (while scoped to this project) pretty much do anything anywhere! I think global roles is a great step in the right direction, but beyond
and after that we need to seriously start looking at making scope itself matter, so that giving someone 'admin' or some such on a project actually only gives them something akin to project_admin or some sort of admin-lite powers scoped to that project and
sub-projects. That though falls into the policy work being done, but should be noted, as it is related.<br>
<br>
Still, at least global scope for roles make the superuser case make some actual sense, because (and I can't speak for other deployers), we have one project pretty much dedicated as an "admin_project" and it's just odd to actually need to give our service users
roles in a project when that project is empty and a pointless construct for their purpose.<br>
<br>
Also thanks for pushing this! I've been watching your global roles spec review in hopes we'd go down that path. :)<br>
<br>
-Adrian<br>
</div>
</div>
<pre>______________________________<wbr>_________________
OpenStack-operators mailing list
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<wbr>openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a>
</pre>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</body>
</html>