[openstack-dev] [keystone][reseller] New way to get a project scoped token by name
David Chadwick
d.w.chadwick at kent.ac.uk
Sat Jun 6 10:01:10 UTC 2015
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
>
> 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
>
More information about the OpenStack-dev
mailing list