Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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
[openstack-dev] [Neutron] - what integration with Keystone is allowed?
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
