Open Stack

>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 <mark at mcclain.xyz> wrote:

>
> On Sep 22, 2014, at 1:20 PM, Monty Taylor <mordred at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141005/2c2f393c/attachment.html>