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

Rodrigo Duarte rodrigodsousa at gmail.com
Thu Jun 4 14:02:00 UTC 2015


First I have some questions: if we are going to add a delimiter, how can we
handle OpenStack API Stability guidelines [1]? If we add this delimiter in
keystone.conf (and having the default value being "." or "/"), do we fall
into the same API stability problems?

Personally, I'm in favor of having a way to represent the hierarchy since
it will loose the naming restrictions across projects and domains entities
- resulting in a better UX. The only remaining restriction will be that we
won't be able to create an entity with the same name in the same level of
the hierarchy. In addition, besides the token request, using a delimiter
also solves the problem of representing a hierarchy in SAML Assertions
generated by a keystone identity provider as well.

Also, if we are going to use a delimiter, we need to update the way
projects names are returned in the GET v3/projects API to include the
hierarchy so the user (or client) knows how to request a token using the
project name.

On Thu, Jun 4, 2015 at 4:33 AM, David Chadwick <d.w.chadwick at kent.ac.uk>
wrote:

> I agree that it is better to choose one global delimiter (ideally this
> should have been done from day one, when hierarchical naming should have
> been used as the basic name form for Openstack). Whatever you choose now
> will cause someone somewhere some pain, but perhaps the overall pain to
> the whole community will be less if you dictate what this delimiter is
> going to be now, but dont introduce for a year. This allows everyone a
> year to remove the delimiter from their names.
>
> regards
>
> David
>
> On 03/06/2015 22:05, 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).
> >
> > 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> = “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://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://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://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?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com <http://lsd.ufcg.edu.br/%7Erodrigods>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/78c170f1/attachment.html>


More information about the OpenStack-dev mailing list