Open Stack

You have to ask, where does the Swift client get the tenant_Id from? 
Isnt it Keystone? So if Keystone returns project_ID:tenant_Id to swift 
as the project_id string, then Swift can continue to use this as if 
nothing has changed. Its just a string whose content has no meaning to 
Swift, but whose content does have meaning to Keystone. The Swift policy 
simply needs to change the value of the tenant_id in its policy to the 
new value and it should work the same

regards

David


On 09/01/2013 20:21, heckj wrote:
> 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
>