The alternative is to explicitly list the delimiter in the project (
e.g. {"hierarchy": {"delim": ".", "domain.project.project2"}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
<d.w.chadw...@kent.ac.uk <mailto:d.w.chadw...@kent.ac.uk>> wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
> Hi David,
>
> You mean creating some kind of "delimiter" attribute in the domain
> entity? That seems like a good idea, although it does not
solve the
> problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
>
> Henrique
>
> Em qua, 3 de jun de 2015 às 04:21, David Chadwick
> <d.w.chadw...@kent.ac.uk <mailto:d.w.chadw...@kent.ac.uk>
<mailto:d.w.chadw...@kent.ac.uk
<mailto:d.w.chadw...@kent.ac.uk>>> escreveu:
>
>
>
> On 02/06/2015 23:34, Morgan Fainberg wrote:
> > Hi Henrique,
> >
> > I don't think we need to specifically call out that we
want a
> domain, we
> > should always reference the namespace as we do today.
Basically, if we
> > ask for a project name we need to also provide it's
namespace (your
> > option #1). This clearly lines up with how we handle
projects in
> domains
> > today.
> >
> > I would, however, focus on how to represent the
namespace in a single
> > (usable) string. We've been delaying the work on this
for a while
> since
> > we have historically not provided a clear way to delimit the
> hierarchy.
> > If we solve the issue with "what is the delimiter"
between domain,
> > project, and subdomain/subproject, we end up solving the
usability
>
> why not allow the top level domain/project to define the
delimiter for
> its tree, and to carry the delimiter in the JSON as a new
parameter.
> That provides full flexibility for all languages and locales
>
> David
>
> > issues with proposal #1, and not breaking the current
behavior you'd
> > expect with implementing option #2 (which at face value
feels to
> be API
> > incompatible/break of current behavior).
> >
> > Cheers,
> > --Morgan
> >
> > On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
> > <henriquecostatr...@gmail.com
<mailto:henriquecostatr...@gmail.com>
> <mailto:henriquecostatr...@gmail.com
<mailto:henriquecostatr...@gmail.com>>
> <mailto:henriquecostatr...@gmail.com
<mailto:henriquecostatr...@gmail.com>
> <mailto:henriquecostatr...@gmail.com
<mailto:henriquecostatr...@gmail.com>>>> wrote:
> >
> > Hi folks,
> >
> >
> > In Reseller[1], we’ll have the domains concept
merged into
> projects,
> > that means that we will have projects that will
behave as domains.
> > Therefore, it will be possible to have two projects
with the same
> > name in a hierarchy, one being a domain and another
being a
> regular
> > project. For instance, the following hierarchy will
be valid:
> >
> > A - is_domain project, with domain A
> >
> > |
> >
> > B - project
> >
> > |
> >
> > A - project with domain A
> >
> >
> > That hierarchy faces a problem when a user requests
a project
> scoped
> > token by name, once she’ll pass “domain = ‘A’” and
> project.name <http://project.name/> <http://project.name
<http://project.name/>>
> > <http://project.name <http://project.name/>> = “A”.
Currently, we have no way to
> > distinguish which project we are referring to. We
have two
> proposals
> > for this.
> >
> >
> > 1.
> >
> > Specify the whole hierarchy in the token request
body, which
> > means that when requesting a token for the child
project for
> > that hierarchy, we’ll have in the scope field
something like:
> >
> > "project": {
> > "domain": {
> > "name": "A"
> > },
> > "name": [“A”', “B”, “A”]
> > }
> >
> >
> > If the project name is unique inside the domain
(project “B”, for
> > example), the hierarchy is optional.
> >
> >
> > 2.
> >
> > When a conflict happen, always provide a token
to the child
> > project. That means that, in case we have a name
clashing as
> > described, it will only be possible to get a
project scoped
> > token to the is_domain project through its id.
> >
> >
> >
> > The former will give us more clarity and won’t
create any more
> > restrictions than we already have. As a con, we
currently are not
> > able to get the names of projects in the hierarchy
above a given
> > project. Although the latter seems to hurt fewer
people, it
> has the
> > disadvantage of creating another set of constraints
that might
> > difficult the UX in the future.
> >
> >
> > What do you think about that? We want to hear your
oppinion, so we
> > can discuss it at today’s Keystone Meeting.
> >
> >
> > [1]
> >
>
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst
> >
> >
> >
>
__________________________________________________________________________
> > OpenStack Development Mailing List (not for usage
questions)
> > Unsubscribe:
> >
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>>
> >
>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
