Open Stack

Right, I understand that. However, the point is that the tenant name is
being stored outside of Keystone and it doesn't ever appear to be updated.

I had proposed a spec to cache the tenant names for the Big Switch code and
it was declined because of the duplication of information.
On Sep 22, 2014 10:52 AM, "Mohammad Banikazemi" <mb at us.ibm.com> wrote:

> 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.
>
> Best,
>
> Mohammad
>
>
>
> [image: Inactive hide details for Dolph Mathews ---09/22/2014 10:53:29
> AM---On Sun, Sep 21, 2014 at 3:58 PM, Kevin Benton <blak111 at gmai]Dolph
> Mathews ---09/22/2014 10:53:29 AM---On Sun, Sep 21, 2014 at 3:58 PM, Kevin
> Benton <blak111 at gmail.com> wrote: > So based on those guideli
>
> From: Dolph Mathews <dolph.mathews at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> 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 <*blak111 at gmail.com*
> <blak111 at gmail.com>> 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" <*dolph.mathews at gmail.com*
>    <dolph.mathews at gmail.com>> wrote:
>       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 <*blak111 at gmail.com*
>       <blak111 at gmail.com>> 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?
>
>          Thanks
>
>          1. *https://review.openstack.org/#/c/122382*
>          <https://review.openstack.org/#/c/122382>
>          2. *https://review.openstack.org/#/c/118456*
>          <https://review.openstack.org/#/c/118456>
>
>          --
>          Kevin Benton
>
>          _______________________________________________
>          OpenStack-dev mailing list
> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>          <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>       _______________________________________________
>       OpenStack-dev mailing list
> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>       <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>    _______________________________________________
>    OpenStack-dev mailing list
> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140922/2f0cd7fd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140922/2f0cd7fd/attachment.gif>