[openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Adam Young
ayoung at redhat.com
Fri Jun 5 17:02:22 UTC 2015
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.chadwick at kent.ac.uk <mailto:d.w.chadwick at 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.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>
> <mailto:d.w.chadwick at kent.ac.uk <mailto: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>
> > <mailto:henriquecostatruta at gmail.com
> <mailto:henriquecostatruta at gmail.com>>
> > <mailto:henriquecostatruta at gmail.com
> <mailto:henriquecostatruta at gmail.com>
> > <mailto: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> <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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >
> <http://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://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://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150605/31d36893/attachment.html>
More information about the OpenStack-dev
mailing list