Open Stack

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