----- Original Message -----
> From: "Adam Young" <ayo...@redhat.com>
> To: "OpenStack Development Mailing List" <openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
