Open Stack

On 06/04/2015 11:13 PM, Jamie Lennox wrote:
>
> ----- 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?
I think it will trip people up.  It is not an intentional design, but a 
limitation due to historical accident.

>
> 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 thkn so.  I think a very common pattern will be having one project for 
a major application (Trello, Wordpress, Kubernetes) with "dev, qa, 
staging, live"  under it, and now we are telling people they can't have it.

>
> 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.
Yeah, that is not a problem here:  if we nest under a domain, the unique 
is not an issue.
>
> 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.
I would say that hierarchical is well enough trodden territory that we 
should go with what works.  We have DNS, and we have fie systesm, both 
of which people use all the time.  Telling people you can only have one 
subdirectory named conf would not fly. Let's get this right.


>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev