[openstack-dev] [Keystone] Domain and Project naming

David Chadwick d.w.chadwick at kent.ac.uk
Fri Jun 5 15:43:10 UTC 2015


Hi Jamie

I think if we are going for hierarchical names we should do it properly
in one go ie. have a recursive scheme that allows infinite nesting of
name components, and then it will solve all current and future problems.
Having a half baked scheme which only allows one level of nesting, or
requires globally unique name components is only storing up trouble for
the future

regards

David


On 05/06/2015 04:13, Jamie Lennox wrote:
> 
> 
> ----- Original Message -----
>> From: "Adam Young" <ayoung at redhat.com>
>> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
>> Sent: Thursday, 4 June, 2015 2:25:52 PM
>> Subject: [openstack-dev] [Keystone] Domain and Project naming
>>
>> With Hierarchical Multitenantcy, we have the issue that a project is
>> currentl restricted in its naming further than it should be.  The domain
>> entity enforces that all project namess under the domain domain be
>> unique, but really what we should say is that all projects under a
>> single parent project be unique.  However, we have, at present, an API
>> which allows a user to specify the domain either name or id and project
>> again, either by name or ID, but here we care only about the name.  This
>> can be used either in specifying the token, or in operations ion the
>> project API.
>>
>> We should change projec naming to be nestable, and since we don't have a
>> delimiter set, we should expect the names to be an array, where today we
>> might have:
>>
>>          "project": {
>>              "domain": {
>>                  "id": "1789d1",
>>                  "name": "example.com"
>>              },
>>              "id": "263fd9",
>>              "name": "project-x"
>>          }
>>
>> we should allow and expect:
>>
>>          "project": {
>>              "domain": {
>>                  "id": "1789d1",
>>                  "name": "example.com"
>>              },
>>              "id": "263fd9",
>>              "name": [ "grandpa", "dad", "daughter"]
>>          }
>>
>> This will, of course, break Horizon and lots of other things, which
>> means we need a reasonable way to display these paths.  The typical UI
>> approach is a breadcrumb trail, and I think something where we put the
>> segments of the path in the UI, each clickable, should be
>> understandable: I'll defer to the UX experts if this is reasonable or not.
>>
>> The alternative is that we attempt to parse the project names. Since we
>> have not reserved a delimeter, we will break someone somewhere if we
>> force one on people.
>>
>>
>> As an alternative, we should start looking in to following DNS standards
>> for naming projects and hosts.  While a domain should not be required to
>> be a DNS registred domain name, we should allow for the case where a
>> user wants that to be the case, and to synchronize nam,ing across
>> multiple clouds.  In order to enforce this, we would have to have an
>> indicator on a domain name that it has been checked with DNS;  ideally,
>> the user would add a special SRV or Text record or something that
>> Keystone could use to confirm that the user has oked this domain name
>> being used by this cloud...or something perhaps with DNSSEC, checking
>> that auser has permission to assign a specific domain name to a set of
>> resources in the cloud.  If we do that, the projects under that domain
>> should also be valid DNS subzones, and the hosts either  FQDNs or some
>> alternate record...this would tie in Well with Designate.
>>
>> Note that I am not saying "force this"  but rather "allow this" as it
>> will simplify the naming when bursting from cloud to cloud:  the Domain
>> and project names would then be synchronized via DNS regardless of
>> hosting provider.
>>
>> As an added benefit, we could provide a SRV or TEXT record (or some new
>> URL type..I heard one is coming) that describes where to find the home
>> Keystone server for a specified domain...it would work nicely with the
>> K2K strategy.
>>
>> If we go with DNS project naming, we can leave all project names in a
>> flat string.
>>
>>
>> Note that the DNS approach can work even if the user does not wish to
>> register their own DNS.  A hosting provider (I'll pick dreamhost, cuz  I
>> know they are listening)  could say the each of their tenants picks a
>> user name...say that mine i admiyo,  they would then create a subdomain
>> of admiyo.dreamcompute.dreamhost.com.  All of my subprojects would then
>> get additional zones under that.  If I were then to burst from there to
>> Bluebox, the Keystone domain name would be the one that I was assigned
>> back at Dreamhost.
> 
> Back up. Is our current restrictions a problem?
> 
> Even with hierarchical projects is it a problem to say that a project name still must be unique per domain? I get that in theory you might want to be able to identify a nested project by name under other projects but that's not something we have to allow immediately.
> 
> I haven't followed the reseller case closely but in any situation where you had off control like that we are re-establishing a domain and so in a multitenancy situation each domain can still use their own project names. 
> 
> I feel like discussions around nested naming schemes and tieing domains to DNS is really premature until we have people that are actually using hierarchical projects. 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list