Open Stack

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
>