<font size=2 face="Arial">What about using the same convention of </font><font size=2 face="sans-serif"> </font><tt><font size=2>http://{SWIFT_IP}/v1/AUTH_{TENANT_ID},
</font></tt><font size=2 face="Arial">but allowing to replace the reseller
prefix of "AUTH_" with the domain identifier when required? On
the one hand, this will be optional and will allow backwards compatibility.
On the other hand, for some architectures, this will allow reflecting the
domain in the URL, supporting private namespaces. As far as I understand,
the reseller prefix (AUTH_) is something optional and is not used in most
architectures (i.e. equals to the default AUTH_). So may be it is ok to
allow some architectures to align it with the domain id. </font>
<br>
<br><font size=2 face="Arial">Best regards,</font>
<br><font size=2 face="Arial">Alex. </font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Chuck Thier <cthier@gmail.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/01/2013 10:15 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[swift] [keystone] Keystone v3 API domains in Swift</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Things are always easy, until you start thinking about
backwards<br>
compatibility. The storage urls for swift with keystone are currently<br>
keyed off of the tenant_id (soon to be project_id), so you end up with<br>
an endpoint url that looks something like<br>
http://{SWIFT_IP}/v1/AUTH_{TENANT_ID} if you change that by adding<br>
the domain, then you break any current users in your system, and you<br>
can't use v2 and v3 auth contracts simultaneously.<br>
<br>
--<br>
Chuck<br>
<br>
On Wed, Jan 9, 2013 at 1:37 PM, David Chadwick <d.w.chadwick@kent.ac.uk>
wrote:<br>
> I would have thought that the solution is conceptually rather<br>
> straightforward. If domains can have their own project names and usernames,<br>
> then you prefix the names with the domain ID or domain name to make
them<br>
> globally unique again.<br>
><br>
> regards<br>
><br>
> David<br>
><br>
><br>
><br>
> On 09/01/2013 19:14, Yee, Guang wrote:<br>
>><br>
>> Yes. Swift ACLs <tenant_id>:<user_name>, <tenant_id>:<user_name>,
and<br>
>> *:<user_name> will be impacted if project (formely tenant)
name and user<br>
>> name are no longer globally unique. We'll need to figure out a
migration<br>
>> path before relaxing that constraint.<br>
>><br>
>><br>
>> Guang<br>
>><br>
>><br>
>> -----Original Message-----<br>
>> From: Chuck Thier [</font></tt><a href=mailto:cthier@gmail.com><tt><font size=2>mailto:cthier@gmail.com</font></tt></a><tt><font size=2>]<br>
>> Sent: Wednesday, January 09, 2013 10:48 AM<br>
>> To: OpenStack Development Mailing List<br>
>> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API
domains in<br>
>> Swift<br>
>><br>
>> Se responses inline:<br>
>><br>
>> On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash <henryn@linux.vnet.ibm.com><br>
>> wrote:<br>
>>><br>
>>> So there are a couple of issues intertwined in this thread:<br>
>>><br>
>>> 1) Uniqueness of identifiers in Swift given the keystone Identity
v3 api.<br>
>>> This is the issue of whether Swift uses tenant names (now
called project<br>
>>> names) at all to uniquely identify any objects - if it did,
then it would<br>
>>> need to also consider storing a domain name or id. From
the discussion,<br>
>><br>
>> it<br>
>>><br>
>>> sounds like tenant/project ID is used instead, which (from
a uniqueness<br>
>>> point of view) is fine. A separate issue exists needs
to be discussed<br>
>>> around swift ACLs and whether username potentially becoming
unique only<br>
>>> within a domain will have an impact.<br>
>>><br>
>><br>
>> For AuthN, you are correct, in that it only relies on tenant/project<br>
>> ID. So, nothing has to be changed from that perspective.
AuthZ is a<br>
>> little more tricky. For ACLs with keystone, they are set as<br>
>> TENANT:USER in any of the following patterns:<br>
>><br>
>> *:user_name - that user from any tenant has access<br>
>> tenant_id:user_name - that user from that tenant id has access<br>
>> tenant_name:user_name - that user from that tenant name has access<br>
>><br>
>> If project_name will not be unique in v3, then the<br>
>> tenant_name:user_name format may have to be deprecated.<br>
>><br>
>> I would be interested to hear from providers that are using keystone<br>
>> with swift and hear which of the above use cases they are using.<br>
>><br>
>><br>
>>> 2) Given that keystone identity v3 domains are likely to be
usually used<br>
>><br>
>> to<br>
>>><br>
>>> represent an enterprise (or "account holder" in
common cloud terminology)<br>
>>> and contain the collection of projects owned by that enterprise,
is it<br>
>>> important for Swift to have that domain knowledge? Will
there be<br>
>><br>
>> operations<br>
>>><br>
>>> either within swift (or more likely layered on top of swift)
that need<br>
>><br>
>> that<br>
>>><br>
>>> information? E.g. How would someone layer a billing
engine on top of<br>
>><br>
>> swift<br>
>>><br>
>>> that could collate all the swift containers that were part
of one domain?<br>
>>> Obviously that engine could call keystone with each project_id
in turn<br>
>>> and<br>
>>> find the domain_id.....but that sounds pretty inefficient.<br>
>>><br>
>><br>
>> As is, containers can already be collated for a given tenant/project<br>
>> id. The containers for a domain is then an aggregate of
the project<br>
>> ids associated to that domain.<br>
>><br>
>> I think the default should be that domains are not mapped in swift.
I<br>
>> believe that this will also be required to facilitate backwards<br>
>> compatibility, which brings up another interesting question --
Is<br>
>> there an expectation that people will be able to run keystone
auth<br>
>> v2.0 and v3.0 side by side?<br>
>><br>
>> --<br>
>> Chuck<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.org<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.org<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>