Open Stack

On Wed, Jun 3, 2015 at 11:25 PM, Adam Young <ayoung at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/9da1b0db/attachment.html>