<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>Whatever name a container for global objects has - or if one or more even exist – is only relevant to a specific implementation and not canonical. It fits better as a configuration than as a core part of the API or code. Even in the same LDAP system, an
operator may have their own unique implementation. Take, as an example, Active Directory with it's default setup. Some enterprises may use the BuiltIn container where 'global' entities live. Others may use the Users container. And some may create their own
containers or OU. Some may want to map role assignments to group membership in certain groups (ex. If a user is a member of Domain Admins, have Keystone report them as having the keystone:admin role).</div>
<div><br>
</div>
<div>I posit that a construct like a 'global' tenant is artificial and not driven from a generic, canonical use case. It is actually
<span style="font-style: italic">not</span> a tenant. And by adopting it we assume the risk of a collision with a backend that defines a 'global' tenant with a different semantic and we don't get much return for that risk.</div>
<div><br>
</div>
<div>
<div>I agree we should provide an out-of-the-box reference implementation, but we should keep Keystone acting as a metasystem that allows mapping the OpenStack use cases back to any operator implementation.</div>
</div>
<div><br>
</div>
<div>Look for an an LDAP implementation to come very soon … and we should pick the thread back up with more concrete examples?</div>
<div><br>
</div>
<div>Kind regards,</div>
<div>Z</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Thor Wolpert <<a href="mailto:thor@wolpert.ca">thor@wolpert.ca</a>><br>
<span style="font-weight:bold">Date: </span>Wed, 13 Jul 2011 17:17:03 -0700<br>
<span style="font-weight:bold">To: </span>Ziad Sawalha <<a href="mailto:ziad.sawalha@rackspace.com">ziad.sawalha@rackspace.com</a>><br>
<span style="font-weight:bold">Cc: </span>Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>, Bryan Taylor <<a href="mailto:btaylor@rackspace.com">btaylor@rackspace.com</a>>, "<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>"
<<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack] OpenStack Identity: Keystone API Proposal<br>
</div>
<div><br>
</div>
If they had called it "global" or some other container name, would you be happier with that? If you're trying to leverage some LDAP style framework, then you'd always want users in some container instead of at the raw root.
<div><br>
</div>
<div>Maybe some guidance or default schema would help those groups out?</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Wed, Jul 13, 2011 at 2:12 PM, Ziad Sawalha <span dir="ltr">
<<a href="mailto:ziad.sawalha@rackspace.com">ziad.sawalha@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
And some current Nova users have created 'dummy' tenants to house global<br>
users. That's ugly and hard to maintain, so we wanted to avoid 'dummy'<br>
tenant solutions if possible. Given we're creating the spec right here and<br>
now, we can do that :-)<br>
<br>
<br>
<br>
On 7/13/11 12:14 PM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
<br>
>On Wed, Jul 13, 2011 at 12:30 PM, Bryan Taylor <<a href="mailto:btaylor@rackspace.com">btaylor@rackspace.com</a>><br>
>wrote:<br>
>> How is this different in effect than letting swift or nova be tenants?<br>
>>Each<br>
>> tenant gets to define users, roles, and groups, right?<br>
><br>
>A service can have multiple tenants. For instance, an installation of<br>
>Nova might have a RAX tenant and a RAX-INTERNAL tenant, both of which<br>
>can create users and roles separately. Keystone can manage these sets<br>
>of users independently, but when the Nova service requests information<br>
>from Keystone, supplying the tenant and user, which depending on the<br>
>information stored in Keystone, could return different role/group<br>
>infomation.<br>
><br>
>-jay<br>
><br>
>_______________________________________________<br>
>Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
This email may include confidential information. If you received it in error, please delete it.<br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
</div>
<br>
</div>
</span>
<font face="monospace">This email may include confidential information. If you received it in error, please delete it.</font></body>
</html>