Open Stack

I agree with Joe, as long as project-id/tenant-id used no change necessary.
Only API calls that take project-name would need to be concatenated with domainid (or name).
Malini

-----Original Message-----
From: heckj [mailto:heckj at mac.com] 
Sent: Wednesday, January 09, 2013 12:21 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift

Given that domains are a segmentation of projects/tenants, then I wouldn't expect to want to change it from a project_id representation to anything else. 

-joe

On Jan 9, 2013, at 12:13 PM, Chuck Thier <cthier at gmail.com> wrote:
> 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
> 
> _______________________________________________
> 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