Open Stack

Things are always easy, until you start thinking about backwards
compatibility.  The storage urls for swift with keystone are currently
keyed off of the tenant_id (soon to be project_id), so you end up with
an endpoint url that looks something like
http://{SWIFT_IP}/v1/AUTH_{TENANT_ID}  if you change that by adding
the domain, then you break any current users in your system, and you
can't use v2 and v3 auth contracts simultaneously.

--
Chuck

On Wed, Jan 9, 2013 at 1:37 PM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
> I would have thought that the solution is conceptually rather
> straightforward. If domains can have their own project names and usernames,
> then you prefix the names with the domain ID or domain name to make them
> globally unique again.
>
> regards
>
> David
>
>
>
> On 09/01/2013 19:14, Yee, Guang wrote:
>>
>> Yes. Swift ACLs <tenant_id>:<user_name>, <tenant_id>:<user_name>, and
>> *:<user_name> will be impacted if project (formely tenant) name and user
>> name are no longer globally unique. We'll need to figure out a migration
>> path before relaxing that constraint.
>>
>>
>> Guang
>>
>>
>> -----Original Message-----
>> From: Chuck Thier [mailto:cthier at gmail.com]
>> Sent: Wednesday, January 09, 2013 10:48 AM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in
>> Swift
>>
>> Se responses inline:
>>
>> On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash <henryn at linux.vnet.ibm.com>
>> wrote:
>>>
>>> So there are a couple of issues intertwined in this thread:
>>>
>>> 1) Uniqueness of identifiers in Swift given the keystone Identity v3 api.
>>> This is the issue of whether Swift uses tenant names (now called project
>>> names) at all to uniquely identify any objects - if it did, then it would
>>> need to also consider storing a domain name or id.  From the discussion,
>>
>> it
>>>
>>> sounds like tenant/project ID is used instead, which (from a uniqueness
>>> point of view) is fine.  A separate issue exists needs to be discussed
>>> around swift ACLs and whether username potentially becoming unique only
>>> within a domain will have an impact.
>>>
>>
>> For AuthN, you are correct, in that it only relies on tenant/project
>> ID.  So, nothing has to be changed from that perspective.  AuthZ is a
>> little more tricky. For ACLs with keystone, they are set as
>> TENANT:USER in any of the following patterns:
>>
>> *:user_name - that user from any tenant has access
>> tenant_id:user_name - that user from that tenant id has access
>> tenant_name:user_name - that user from that tenant name has access
>>
>> If project_name will not be unique in v3, then the
>> tenant_name:user_name format may have to be deprecated.
>>
>> I would be interested to hear from providers that are using keystone
>> with swift and hear which of the above use cases they are using.
>>
>>
>>> 2) Given that keystone identity v3 domains are likely to be usually used
>>
>> to
>>>
>>> represent an enterprise (or "account holder" in common cloud terminology)
>>> and contain the collection of projects owned by that enterprise, is it
>>> important for Swift to have that domain knowledge?  Will there be
>>
>> operations
>>>
>>> either within swift (or more likely layered on top of swift) that need
>>
>> that
>>>
>>> information?  E.g. How would someone layer a billing engine on top of
>>
>> swift
>>>
>>> that could collate all the swift containers that were part of one domain?
>>> Obviously that engine could call keystone with each project_id in turn
>>> and
>>> find the domain_id.....but  that sounds pretty inefficient.
>>>
>>
>> As is, containers can already be collated for a given tenant/project
>> id.  The containers for a domain is then an aggregate of the project
>> ids  associated to that domain.
>>
>> I think the default should be that domains are not mapped in swift.  I
>> believe that this will also be required to facilitate backwards
>> compatibility, which brings up another interesting question -- Is
>> there an expectation that people will be able to run keystone auth
>> v2.0 and v3.0 side by side?
>>
>> --
>> Chuck
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev