On Wed, Jun 3, 2015 at 11:25 PM, Adam Young <ayo...@redhat.com> wrote:
> 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"] > } > What is the actual project name here, and how do I specify it using my existing OS_PROJECT_NAME environment variable? > > 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. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev