On 06/04/2015 10:49 PM, Dolph Mathews wrote:
On Wed, Jun 3, 2015 at 11:25 PM, Adam Young <[email protected]
<mailto:[email protected]>> 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:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
