[openstack-dev] [keystone][reseller] New way to get a project scoped token by name

Dolph Mathews dolph.mathews at gmail.com
Tue Jun 9 14:57:32 UTC 2015


On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox <jamielennox at redhat.com>
wrote:

>
>
> ----- 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.
>

+1


>
>
>
> > >
> > > 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
> >
>
> __________________________________________________________________________
> 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/20150609/f476dc88/attachment.html>


More information about the OpenStack-dev mailing list