I am sure I have missed something along the way, but can someone explain to me
why we need this at all. Project names are unique within a domain, with the
exception of the project that is acting as its domain (i.e. they can only every
be two names clashing in a hierarchy at the domain level and below). So why
isn’t specifying “is_domain=True/False” sufficient in an auth scope along with
the project name?
Henry
> On 5 Jun 2015, at 18:02, Adam Young <ayo...@redhat.com> wrote:
>
> On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
>> Hi David,
>>
>> There needs to be some form of global hierarchy delimiter - well more to the
>> point there should be a common one across OpenStack installations to ensure
>> we are providing a good and consistent (and more to the point
>> inter-operable) experience to our users. I'm worried a custom defined
>> delimiter (even at the domain level) is going to make it difficult to
>> consume this data outside of the context of OpenStack (there are
>> applications that are written to use the APIs directly).
> We have one already. We are working JSON, and so instead of project name
> being a string, it can be an array.
>
> Nothing else is backwards compatible. Nothing else will ensure we don;t
> break exisiting deployments.
>
> Moving forward, we should support DNS notation, but it has to be an opt in
>
>>
>> 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
>> >
>> > <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
>> > <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
>> > <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
>> > <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
>> > <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
>> <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
>> <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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
__________________________________________________________________________
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
