Open Stack

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.