[openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Jamie Lennox
jamielennox at redhat.com
Tue Jun 9 03:44:48 UTC 2015
----- Original Message -----
> From: "David Chadwick" <d.w.chadwick at kent.ac.uk>
> To: openstack-dev at lists.openstack.org
> Sent: Saturday, 6 June, 2015 6:01:10 PM
> Subject: Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
>
>
>
> On 06/06/2015 00:24, Adam Young wrote:
> > On 06/05/2015 01:15 PM, Henry Nash wrote:
> >> 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?
> >
> > The limitation of " Project names are unique within a domain" is
> > artificial and somethi8ng we should not be enforcing. Names should only
> > be unique within parent project.
>
> +++1
I said the exact same thing as Henry in the other thread that seems to be on the same topic. You're correct the limitation of "Project names are unique within a domain" is completely artificial, but it's a constraint that allows us to maintain the auth systems we currently have and will not harm the reseller model (because they would be creating new domains).
It's also a constraint that we can relax later when multitenancy is a bit more established and someone has a real issue with the limitation - it's not something we can ever claw back again if we allow some looking up projects by name with delimiters.
I think for the time being it's an artificial constraint we should maintain.
> >
> > This whole thing started by trying to distinguish a domain from a
> > project within that domain that both have the same name. We can special
> > case that, but it is not a great solution.
> >
> >
> >
> >>
> >> Henry
> >>
> >>> On 5 Jun 2015, at 18:02, Adam Young <ayoung at redhat.com
> >>> <mailto:ayoung at 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.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/>>
> >>>> > > <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://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://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://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
> >>>
> >>> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
> >>> <mailto: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
> >
> >
> >
> > __________________________________________________________________________
> > 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
>
More information about the OpenStack-dev
mailing list