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" <[email protected]> >> To: "OpenStack Development Mailing List" <[email protected]> >> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
