Open Stack

On 06/04/2015 10:49 PM, Dolph Mathews wrote:
>
>
> On Wed, Jun 3, 2015 at 11:25 PM, Adam Young <ayoung at redhat.com 
> <mailto: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 <http://example.com>"
>                 },
>                 "id": "263fd9",
>                 "name": "project-x"
>             }
>
>     we should allow and expect:
>
>             "project": {
>                 "domain": {
>                     "id": "1789d1",
>                     "name": "example.com <http://example.com>"
>                 },
>                 "id": "263fd9",
>                 "name": [ "grandpa", "dad", "daughter"]
>             }
>
>
> What is the actual project name here,
In Python and JSON it is

[ "grandpa", "dad", "daughter"]

> and how do I specify it using my existing OS_PROJECT_NAME environment 
> variable?

Probalby the simplest would be to quote it, and use single quotes for 
the inner strings like this:


"[ 'grandpa', 'dad', 'daughter']"

for person in  "[ 'grandpa', 'dad', 'daughter']" ; do echo $person; done
[ 'grandpa', 'dad', 'daughter']


For the CLI, it might be possible to specify multiple values such as

--os-project-name= "grandpa" "dad" "daughter"
or
--os-project-name= "grandpa" --os-project-name="dad" 
--os-project-name="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
>     <http://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://OpenStack-dev-request@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-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/20150605/0d2b382c/attachment.html>