Open Stack

Chuck,

So user_id and project_id are always globally unique - so we are safe there.  The problem is when you specify user name or project name in the cases when we have to handle enterprises being represented by a domain and they insist that their name attributes (e.g. user names, project names etc.) be private to that domain (e.g. "what do you mean I can't call my project "Test" because some other customer in another domain got there first!?!").  See the following blueprint which introduces this ability as optional for domains: https://review.openstack.org/#/c/18805/

For such domains, we cannot assume that user_name or project_name (or tenant_name as it used to be called) are globally unique.  "Domain_name (or id) plus user_name" as well as  "Domain_name (or id) plus project_name" will be unique however.

Henry
On 8 Jan 2013, at 19:05, Chuck Thier wrote:

> Yeah, I was hoping for more clarity, as it would help to figure out
> how to best map the concepts in swift.  A couple of quick questions
> come to mind.  When a request is validated, is the domain required, or
> is a user_id and project_id sufficient?  Is the concept of a domain
> useful in the context of swift?
> 
> --
> Chuck
> 
> On Tue, Jan 8, 2013 at 11:37 AM, heckj <heckj at mac.com> wrote:
>> The best is probably https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md, but it's a bit light on use-cases around the concepts I'm afraid.
>> 
>> -joe
>> 
>> On Jan 8, 2013, at 9:19 AM, Chuck Thier <cthier at gmail.com> wrote:
>>> Is there documentation anywhere that defines all of these, and the use
>>> cases?  That would help us figure out how to map these concepts to
>>> swift.
>>> 
>>> --
>>> Chuck
>>> 
>>> On Tue, Jan 8, 2013 at 11:13 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>>>> I think it would be practical to expose the authenticated user's DOMAIN_ID
>>>> and DOMAIN_NAME into the request environment for the underlying service /
>>>> middleware to consume, as we do today with TENANT_ID / TENANT_NAME (soon to
>>>> be deprecated in favor of PROJECT_ID / PROJECT_NAME).
>>>> 
>>>> 
>>>> -Dolph
>>>> 
>>>> 
>>>> On Tue, Jan 8, 2013 at 7:22 AM, Alexandra Shulman-Peleg
>>>> <SHULMANA at il.ibm.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> As most of you know, Keystone v3 API will introduce the notions of
>>>>> "domains" and "projects" which will replace the existing notion of tenants.
>>>>> It is important to allow using the same concepts in Swift. Since different
>>>>> domains may represent different companies, it is important to allow
>>>>> reflecting the Keystone "domain name" in the Swift "account name", providing
>>>>> an option to isolate the requests of different domains. Are there existing
>>>>> plans of adjusting Swift to Keystone v3 API? If not, I would like to start
>>>>> discussing the potential solutions.
>>>>> 
>>>>> Thank you all,
>>>>> Alex.
>>>>> 
>>>>> 
>>>>> ----------------------------------------------------------
>>>>> Alexandra Shulman-Peleg, PhD
>>>>> Storage Research, Cloud Platforms Dept.
>>>>> IBM Haifa Research Lab
>>>>> Tel: +972-3-7689530 | Fax: +972-3-7689545
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>