Open Stack

The Tenant_ID is in the URL
(https://{SWIFT_IP}/v1/AUTH_{TENANT_ID}/{CONTAINER}/{OBJECT})

I think we have beaten this part to death a bit now, as we seem to all
agree that we can continue this pattern with the V3 API.  The one
concern that I still have is how the ACLs will work, and weather or
not that will need to change.

I'm also curious how the Keystone V3 API will work alongside V2 apis.

--
Chuck

On Thu, Jan 10, 2013 at 4:16 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
> 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
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev