Open Stack

+1 for X-Domain-Id and X-Domain-Name.

I hope other projects don't need to be concerned about the namespace of a
domain, as they should assume that names of any kind may collide (including
domain names). You're right though: a privately namespaced domain may
result in conflicting ACL entries given that two user names from (at least
one) privately namespaced domain(s) may collide.

project_id + user_id would get around that, or project_id + (domain_id +
user_name).

If we don't work out the full implementation across openstack prior to
grizzly, we need to pull private namespacing from the current spec, and
leave names as globally unique for now.

-Dolph


On Wed, Jan 23, 2013 at 2:39 PM, Yee, Guang <guang.yee at hp.com> wrote:

> Swift ACLs currently can be specified as****
>
> ** **
>
> <project/tenant ID>:<username>****
>
> <project/tenant name>:<username>****
>
> *:<username>****
>
> ** **
>
> IDs are always globally unique regardless. Names (username, project/tenant
> name, etc), on the other hand, are currently required to be globally
> unique. But there are attempts to relax the globally uniqueness on names
> constraint. The notion of private domain is one of them. I am still unclear
> on how private domains will impact the existing services.****
>
> ** **
>
> **1.      **How does private domain work in conjunction with public
> domains? If I have a user jdoe in private domain XYZ and another jdoe in a
> public domain ABC, how does not affect the existing Swift ACLs? Seems to
> me, private domain or not, Swift ACL will have to change once we relax this
> constraint.****
>
> **2.      **How does private domain affect middleware? Are we going to
> have a X-Domain-ID, X-Domin-Name, and X-Is-Private-Domain headers?****
>
> ** **
>
> I think we need a full impact assessment before moving forward with this.*
> ***
>
> ** **
>
> ** **
>
> Guang****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Dolph Mathews [mailto:dolph.mathews at gmail.com]
> *Sent:* Wednesday, January 23, 2013 9:52 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains
> in Swift****
>
> ** **
>
> On the surface, this seems to be defeating the purpose of introducing
> domains in the first place (allowing domain administrators to manage
> isolated groups of users & projects). I'm not sure why you'd need to switch
> away from tenant_id/project_id.****
>
>
> ****
>
> ** **
>
> -Dolph****
>
> ** **
>
> On Wed, Jan 23, 2013 at 4:23 AM, Alexandra Shulman-Peleg <
> SHULMANA at il.ibm.com> wrote:****
>
> Hi,
>
> I would like to get back to this discussion and specify the exact syntax
> of ACLs that can be used when removing the global uniqueness constraint on
> user names. I wander whether we really need to prefix both the project_name
> and the username with the domain id? Especially, since on ACLs we mainly
> need to properly identify the user and not the project. So the notion of a
> project may not be required in this context? For example, in NFSv4 ACLs
> (also adopted by CDMI) users are identified by username at domain. So I
> wander whether on ACLs, in V3 we can simply switch from tenant_id:username
> to domain_id:username? This seems to fulfill the identification
> requirements and will give a very simple solution for the migration of
> existing v2 customers to private domains in V3 – assigning the new
> domain_id to match the old tenant_id will allow preserving all of the
> stored containers without the need to modify the containers' meta data.
>
> Best Regards,
> Alex.
>
>
>
> From:        "Yee, Guang" <guang.yee at hp.com>
> To:        OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>,
> Date:        11/01/2013 10:31 PM ****
>
> Subject:        Re: [openstack-dev] [swift] [keystone] Keystone v3 API
> domains in Swift ****
> ------------------------------
>
>
>
>
> As long as Swift URL stay the same we should be OK. Frankly, there aren't
> any strong arguments for changing it at this point. Whenever we remove the
> globally uniqueness constraint on names, new Swift ACLs probably will need
> to switch over to using namespacing.
>
> domain_name.project_name:domain_name.username
>
> something like that. Existing Swift ACLs should work fine since if the
> given
> domain is the default (migrated) system domain, auth_token middleware
> should
> not set the domains headers.
>
>
> Guang
>
>
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk<d.w.chadwick at kent.ac.uk>]
>
> Sent: Friday, January 11, 2013 8:36 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in
> Swift
>
> Hi Chuck
>
> On 11/01/2013 15:59, Chuck Thier wrote:
> > 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.
>
> My opinion (only, I dont speak for anyone else) is as follows:
>
> 1. A v2 API system has no problems as it is working OK today
> 2. A v3 API system only, with domains added, should work OK tomorrow
> otherwise the v3 API has problems
> 3. So the main point as you say is how do v2 and v3 systems interwork. I
> suggest there is an intercept module, say in the Keystone pipeline, that
> knows it is operating in a v2/v3 environment, and when it receives a v2
> request already containing a tenant_ID it knows it will comprise
> domain:project and it can unpack it, and give the separate elements to
> the rest of the V3 code for processing as in a v3 system. When the
> intercept module receives a v2 request that needs a tenant ID returning
> to it, it will encode up the domain and project as a tenant ID, and
> return this to the v2 client. The v2 client will be blissfully unaware
> that what it thinks is a tenant ID is actually a combination of domain
> and project.
>
> regards
>
> david
>
>
>
> >
> > --
> > 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 <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
> >
> > _______________________________________________
> > 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****
>
>
> [attachment "smime.p7s" deleted by Alexandra Shulman-Peleg/Haifa/IBM]
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130123/f3edc6cc/attachment-0001.html>