In the patch being referred to here and in the IBM controller, the project
ID is the unique identifier used. The name is simply an additional piece of
information that may perhaps be used for debugging. The back-end
(controller) keeps a name not as a unique identifier but in addition to the
unique identifier which is the project ID. For all practical purposes, we
can set the project name for all projects to Kevin Benton and nothing will
change functionally.

This should be obvious from the code and how the project id and not the
name has been used in the plugin. Perhaps the commit message can specify
this clearly to avoid any confusion.



From:   Dolph Mathews <>
To:     "OpenStack Development Mailing List (not for usage questions)"
Date:   09/22/2014 10:53 AM
Subject:        Re: [openstack-dev] [Neutron] - what integration with Keystone
            is  allowed?

On Sun, Sep 21, 2014 at 3:58 PM, Kevin Benton <> wrote:
  So based on those guidelines there would be a problem with the IBM patch
  because it's storing the tenant name in a backend controller, right?

It would need to be regarded as an expiring cache if Neutron chose to go
that route. I'd wholly recommend against it though, because I don't see a
strong use case to use names instead of IDs here (correct me if I'm wrong).

  On Sep 21, 2014 12:18 PM, "Dolph Mathews" <>
   Querying keystone for tenant names is certainly fair game.

   Keystone should be considered the only source of truth for tenant names
   though, as they are mutable and not globally unique on their own, so
   other services should not stash any names from keystone into long term
   persistence (users, projects, domains, groups, etc-- roles might be an
   odd outlier worth a separate conversation if anyone is interested).

   Store IDs where necessary, and use IDs on the wire where possible
   though, as they are immutable.

   On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton <> wrote:
     Hello all,

     A patch has come up to query keystone for tenant names in the IBM
     plugin.[1] As I understand it, this was one of the reasons another
     mechanism driver was reverted.[2] Can we get some clarity on the level
     of integration with Keystone that is permitted?



     Kevin Benton

     OpenStack-dev mailing list

   OpenStack-dev mailing list

  OpenStack-dev mailing list

OpenStack-dev mailing list
OpenStack-dev mailing list

Reply via email to