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 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
> 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 = “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.
>
>
> 1.
>
> 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://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
