[openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Raildo Mascena
raildom at gmail.com
Thu Jun 11 14:06:25 UTC 2015
Hi Folks,
As we have discussed in the last Keystone meeting, we created an etherpad
with the alternatives to solve this problem:
https://etherpad.openstack.org/p/reseller-project-token
We have also decided to take a vote to choose the best option in the next
Keystone Meeting (#openstack-meeting - June 16th - 18:00 UTC).
It would be great if you could take a look before the meeting, so we could
discuss and improve this document before the vote.
Best regards,
On Tue, Jun 9, 2015 at 12:12 PM Dolph Mathews <dolph.mathews at gmail.com>
wrote:
> 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
>>
> __________________________________________________________________________
> 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/20150611/3c808391/attachment.html>
More information about the OpenStack-dev
mailing list