>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
