<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/04/2015 10:49 PM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gW8U7hF8iWDqzhXeb-WP7C+SNi3YDLRz5y3F6+36OErxg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jun 3, 2015 at 11:25 PM, Adam
Young <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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:<br>
<br>
"project": {<br>
"domain": {<br>
"id": "1789d1",<br>
"name": "<a moz-do-not-send="true"
href="http://example.com" target="_blank">example.com</a>"<br>
},<br>
"id": "263fd9",<br>
"name": "project-x"<br>
}<br>
<br>
we should allow and expect:<br>
<br>
"project": {<br>
"domain": {<br>
"id": "1789d1",<br>
"name": "<a moz-do-not-send="true"
href="http://example.com" target="_blank">example.com</a>"<br>
},<br>
"id": "263fd9",<br>
"name": [ "grandpa", "dad", "daughter"]<br>
}<br>
</blockquote>
<div><br>
</div>
<div>What is the actual project name here,</div>
</div>
</div>
</div>
</blockquote>
In Python and JSON it is<br>
<br>
[ "grandpa", "dad", "daughter"]<br>
<br>
<blockquote
cite="mid:CAC=h7gW8U7hF8iWDqzhXeb-WP7C+SNi3YDLRz5y3F6+36OErxg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> and how do I specify it using my existing
OS_PROJECT_NAME environment variable?</div>
</div>
</div>
</div>
</blockquote>
<br>
Probalby the simplest would be to quote it, and use single quotes
for the inner strings like this:<br>
<br>
<br>
"[ 'grandpa', 'dad', 'daughter']"<br>
<br>
for person in "[ 'grandpa', 'dad', 'daughter']" ; do echo $person;
done<br>
[ 'grandpa', 'dad', 'daughter']<br>
<br>
<br>
For the CLI, it might be possible to specify multiple values such as
<br>
<br>
--os-project-name= "grandpa" "dad" "daughter"<br>
or<br>
--os-project-name= "grandpa" --os-project-name="dad"
--os-project-name="daughter"<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gW8U7hF8iWDqzhXeb-WP7C+SNi3YDLRz5y3F6+36OErxg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
If we go with DNS project naming, we can leave all project
names in a flat string.<br>
<br>
<br>
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 <a moz-do-not-send="true"
href="http://admiyo.dreamcompute.dreamhost.com"
target="_blank">admiyo.dreamcompute.dreamhost.com</a>.
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.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>