Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-10-05 Thread Kevin Benton
The proposals tradionatlly have Neutron acting as proxy for Keystone vs
having the backend controller request the information directly creates more
problems than it solves.

Can you elaborate on this a bit more? From a driver-author perspective this
is exactly the opposite of what I've observed.

Having the backend controller request the information means the controller
has to understand how to talk to Keystone and has to be configured with
Keystone credentials and a URL. The first step is already a huge barrier
for a system that knows absolutely nothing about what software is being
used to orchestrate it, let alone the specifics of one of its APIs. Even if
you have the ability to write a completely new client on whatever the
network hardware is, that requires completely new user workflows on the
backend side to configure, test, and troubleshoot problems with the
Keystone integration.

Additionally, backend Keystone integration changes the security model
because the network hardware is no longer something that Neutron just
pushes configuration state to. The backend now has to be allowed direct
access to the Keystone server and must be trusted with Keystone
credentials. So we have all of these new problems to deal with, and that's
just to get a tenant name to provide in a description field for an
unfriendly UUID.

For the sake of argument, let's pretend that the above is trivial and that
Keystone integration is free. You still end up with the majority of the
same synchronization problems that would occur if the client was on the
Neutron side. There is no way that Keystone can be queried every single
time the description field is referenced for a tenant object because it
could happen many times per second (e.g. messages being logged or several
users looking at information in the controller, etc.), so we're right back
to square 1 with caching concerns. I don't see how the method of keeping
that cache up-to-date changes with the keystone polling being on the
controller instead of being in Neutron.

On Mon, Sep 22, 2014 at 1:49 PM, Mark McClain m...@mcclain.xyz wrote:


 On Sep 22, 2014, at 1:20 PM, Monty Taylor mord...@inaugust.com wrote:

 On 09/21/2014 10:57 PM, Nader Lahouti wrote:

 Thanks Kevin for bring it up in the ML, I was looking for a guideline or
 any document to clarify issues on this subject.

 I was told, even using keystone API in neutron is not permitted.


 I recognize that I'm potentially without context for neutron internals -
 but could someone please shed some light on why using keystone API from
 neutron would ever be forbidden? That sounds a bit craycray to me and
 I'd like to understand more.


 In the past, the proposed usage of the Keystone API for things other than
 auth have been craycray :) As a response, we’ve established an extremely
 high bar for those wishing to entangle the two. The proposals tradionatlly
 have Neutron acting as proxy for Keystone vs having the backend controller
 request the information directly creates more problems than it solves. I’m
 not opposed to altering our stance, but I’ve yet to see a proposal for a
 Keystone proxy that handles synchronization correctly outside the happy
 path test in a dev environment.

 Ideally, I think something that provides proper sync support should exist
 in Keystone or a Keystone related project vs multiple implementations in
 Neutron, Cinder or any other multi-tenant service that wants to provide
 more human friendly names for a vendor backend.

 mark


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-23 Thread Duncan Thomas
On 22 September 2014 21:49, Mark McClain m...@mcclain.xyz wrote:

 Ideally, I think something that provides proper sync support should exist in
 Keystone or a Keystone related project vs multiple implementations in
 Neutron, Cinder or any other multi-tenant service that wants to provide more
 human friendly names for a vendor backend.

In general in cinder I've opposed making unnecessary calls out to
*any* REST API, keystone, glance, etc, in any common code path,
particularly cinder-api code - it makes it very easy for a blip in one
service, like keystone api, to case a cascading failure as the worker
threads end up all getting consumed blocking waiting for the external
service, then nova blocks all its api threads talking to cinder,
neutron blocks talking to nova, cinder volume actions block calling
nova, etc. Either you then run into a storm of timed out operations,
or a storm of work once the end of the blockage is removed, neither of
which is desirable.

I'd rather not have convenience labels on the backend array than
increase the risks of this sort of failure mode.


-- 
Duncan Thomas

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-22 Thread Dolph Mathews
On Sun, Sep 21, 2014 at 3:58 PM, Kevin Benton blak...@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.math...@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 blak...@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
 2. https://review.openstack.org/#/c/118456

 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-22 Thread Akihiro Motoki
In Keystone, as Dolph says, a tenant name is not globally unique,
so IMHO tenant_id needs to be passed to a back-end controller
to ensure uniqueness of tenant (or project).

tenant_name can be an additional information.
For example it can be used in a GUI of a back-end controller,
so I think it may be useful for some purpose.

Thanks,
Akihiro


On Sun, Sep 21, 2014 at 8:46 AM, Kevin Benton blak...@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
 2. https://review.openstack.org/#/c/118456

 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Akihiro Motoki amot...@gmail.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-22 Thread Monty Taylor
On 09/21/2014 10:57 PM, Nader Lahouti wrote:
 Thanks Kevin for bring it up in the ML, I was looking for a guideline or
 any document to clarify issues on this subject.
 
 I was told, even using keystone API in neutron is not permitted.

I recognize that I'm potentially without context for neutron internals -
but could someone please shed some light on why using keystone API from
neutron would ever be forbidden? That sounds a bit craycray to me and
I'd like to understand more.

 
 
 On Sun, Sep 21, 2014 at 12:58 PM, Kevin Benton blak...@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?
 On Sep 21, 2014 12:18 PM, Dolph Mathews dolph.math...@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 blak...@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
 2. https://review.openstack.org/#/c/118456

 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-22 Thread Mohammad Banikazemi

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





From:   Dolph Mathews dolph.math...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@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 blak...@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.math...@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 blak...@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
 2. https://review.openstack.org/#/c/118456

 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-22 Thread Mohammad Banikazemi


Akihiro Motoki amot...@gmail.com wrote on 09/22/2014 12:50:43 PM:

 From: Akihiro Motoki amot...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 09/22/2014 12:53 PM
 Subject: Re: [openstack-dev] [Neutron] - what integration with
 Keystone is allowed?

 In Keystone, as Dolph says, a tenant name is not globally unique,
 so IMHO tenant_id needs to be passed to a back-end controller
 to ensure uniqueness of tenant (or project).


Yes, that has been the case in this plugin (and the patch in question does
not change that).


 tenant_name can be an additional information.
 For example it can be used in a GUI of a back-end controller,
 so I think it may be useful for some purpose.


Exactly.


Best,

Mohammad


 Thanks,
 Akihiro


 On Sun, Sep 21, 2014 at 8:46 AM, Kevin Benton blak...@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
  2. https://review.openstack.org/#/c/118456
 
  --
  Kevin Benton
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Akihiro Motoki amot...@gmail.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-22 Thread Kevin Benton
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 m...@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@gmai]Dolph
 Mathews ---09/22/2014 10:53:29 AM---On Sun, Sep 21, 2014 at 3:58 PM, Kevin
 Benton blak...@gmail.com wrote:  So based on those guideli

 From: Dolph Mathews dolph.math...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@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 *blak...@gmail.com*
 blak...@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.math...@gmail.com*
dolph.math...@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 *blak...@gmail.com*
   blak...@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@lists.openstack.org* OpenStack-dev@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@lists.openstack.org* OpenStack-dev@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@lists.openstack.org* OpenStack-dev@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-22 Thread Mark McClain

On Sep 22, 2014, at 1:20 PM, Monty Taylor mord...@inaugust.com wrote:

 On 09/21/2014 10:57 PM, Nader Lahouti wrote:
 Thanks Kevin for bring it up in the ML, I was looking for a guideline or
 any document to clarify issues on this subject.
 
 I was told, even using keystone API in neutron is not permitted.
 
 I recognize that I'm potentially without context for neutron internals -
 but could someone please shed some light on why using keystone API from
 neutron would ever be forbidden? That sounds a bit craycray to me and
 I'd like to understand more.

In the past, the proposed usage of the Keystone API for things other than auth 
have been craycray :) As a response, we’ve established an extremely high bar 
for those wishing to entangle the two. The proposals tradionatlly have Neutron 
acting as proxy for Keystone vs having the backend controller request the 
information directly creates more problems than it solves. I’m not opposed to 
altering our stance, but I’ve yet to see a proposal for a Keystone proxy that 
handles synchronization correctly outside the happy path test in a dev 
environment.

Ideally, I think something that provides proper sync support should exist in 
Keystone or a Keystone related project vs multiple implementations in Neutron, 
Cinder or any other multi-tenant service that wants to provide more human 
friendly names for a vendor backend.

mark

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-21 Thread 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 blak...@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
 2. https://review.openstack.org/#/c/118456

 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-21 Thread Kevin Benton
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?
On Sep 21, 2014 12:18 PM, Dolph Mathews dolph.math...@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 blak...@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
 2. https://review.openstack.org/#/c/118456

 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-21 Thread Nader Lahouti
Thanks Kevin for bring it up in the ML, I was looking for a guideline or
any document to clarify issues on this subject.

I was told, even using keystone API in neutron is not permitted.

Thanks,
Nader.


On Sun, Sep 21, 2014 at 12:58 PM, Kevin Benton blak...@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?
 On Sep 21, 2014 12:18 PM, Dolph Mathews dolph.math...@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 blak...@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
 2. https://review.openstack.org/#/c/118456

 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev