Open Stack

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.

Henrique

Em qua, 3 de jun de 2015 às 04:21, David Chadwick <d.w.chadwick at 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
> > <henriquecostatruta at gmail.com <mailto:henriquecostatruta at 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> = “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-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
> >
>
> __________________________________________________________________________
> 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/20150603/9ac1ea59/attachment.html>