[openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Morgan Fainberg
morgan.fainberg at gmail.com
Tue Jun 9 06:43:47 UTC 2015
Sent via mobile
> On Jun 9, 2015, at 05:44, 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
More information about the OpenStack-dev
mailing list