<div dir="ltr">><span style="font-family:arial,sans-serif;font-size:13.5135135650635px">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.</span><div><span style="font-family:arial,sans-serif;font-size:13.5135135650635px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.5135135650635px">Can you elaborate on this a bit more? From a driver-author perspective this is exactly the opposite of what I've observed.</span></div><div><span style="font-family:arial,sans-serif;font-size:13.5135135650635px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.5135135650635px">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. </span></div><div><span style="font-family:arial,sans-serif;font-size:13.5135135650635px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.5135135650635px">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.</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13.5135135650635px"><br></span></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 22, 2014 at 1:49 PM, Mark McClain <span dir="ltr"><<a href="mailto:mark@mcclain.xyz" target="_blank">mark@mcclain.xyz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><div>On Sep 22, 2014, at 1:20 PM, Monty Taylor <<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>> wrote:</div><br><blockquote type="cite"><div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On 09/21/2014 10:57 PM, Nader Lahouti wrote:<br><blockquote type="cite">Thanks Kevin for bring it up in the ML, I was looking for a guideline or<br>any document to clarify issues on this subject.<br><br>I was told, even using keystone API in neutron is not permitted.<br></blockquote><br>I recognize that I'm potentially without context for neutron internals -<br>but could someone please shed some light on why using keystone API from<br>neutron would ever be forbidden? That sounds a bit craycray to me and<br>I'd like to understand more.<br></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>mark</div></font></span></div><br></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>