Open Stack

----- 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.