Open Stack

>From a mapping perspective, might one say the 
"Domain" maps to Swift's "Account"
"Project"  maps to Swift's "Container"

Thanks
Malini

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] 
Sent: Tuesday, January 08, 2013 12:53 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift

Hi Alex

I can agree with you but would go further, in that we need both global roles and local roles. So, if I specify

https://swift/AUTH_>Test

then I am specifying the Test global role, but if I specify

https://swift/AUTH_>{DOMAIN_ID}_{PROJECT_ID}_Test

I am specifying the role Test which is local to the project. Similarly

https://swift/AUTH_>{DOMAIN_ID}_Test

is the Test local role of the domain.

These are unambiguous since the _ is the separator between domains and projects, rather like the . is the separator in domain names.

Note, what you should not be able to do is specify

https://swift/AUTH_>{PROJECT_ID}_Test

as this would be ambiguous. Which domain does it refer to?

regards

David



On 08/01/2013 20:11, Alexandra Shulman-Peleg wrote:
> I think that there is a problem with simply using https://SWIFT/AUTH_ 
> <https://swift/AUTH_>{PROJECT_ID}instead of the current 
> https://SWIFT/AUTH_ <https://swift/AUTH_>{TENANT_ID} since it will 
> loose the proper level in the hierarchy. We need something that will 
> represent the hosted enterprises and this is the goal of domains. 
> Project are more fine-grained and can represent departments or 
> projects.  For example, following the description of Henry if two 
> different enterprises with use the project name "Test" both with map 
> to https://SWIFT/AUTH_ <https://swift/AUTH_>Test.
>
> I think that we need to have both the domain id and the project id in 
> the URL/account name. For example as https://SWIFT/AUTH_ 
> <https://swift/AUTH_>{DOMAIN_ID}_{PROJECT_ID} or as https://SWIFT/ 
> <https://swift/>{DOMAIN_ID}_{PROJECT_ID}. In the second option we may 
> try using the existing reseller prefix mechanism to simplify the 
> implementation. Having the doman_id in the account name/URL is 
> important to isolate the accounts that belong to different domains and 
> remove the requirements for the global uniqueness of project names.
>
> Best Regards,
> Alex.
>
>
>
> From: Chuck Thier <cthier at gmail.com>
> To: OpenStack Development Mailing List 
> <openstack-dev at lists.openstack.org>,
> Date: 08/01/2013 09:38 PM
> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains
> in        Swift
> ----------------------------------------------------------------------
> --
>
>
>
> Hi Henry,
>
>  >From a swift perspective, I think we are fine there, as we do not 
> use the user name or project name anywhere.  At the moment, I'm 
> thinking that we can do auth in a similar way as we did with v2.0 api.  
> An "account" in swift is still tied to the project_id (which used to 
> be tennant_id), which is in the storage url like:
> https://SWIFT/AUTH_ <https://swift/AUTH_>{PROJECT_ID}.  Keystone 
> middleware in swift validates that the given token has permission for 
> the given Project ID.
>
>  >From this point of view domains are an abstract concept in keystone 
> only, and wouldn't mean anything directly in swift.
>
> Please let me know if any of my assumptions are incorrect.
>
> Thanks,
>
> --
> Chuck
>
> On Tue, Jan 8, 2013 at 1:23 PM, Henry Nash <henryn at linux.vnet.ibm.com>
> wrote:
>  > 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-identi
> ty-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
>  >>
>  >
>  >
>  > _______________________________________________
>  > 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