<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 7:13 PM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">


<div>On Fri, Aug 8, 2014 at 5:38 PM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">




<div> One advantage of the service plugin is that one can leverage the neutron common framework such as Keystone authentication where common scoping is done. It would be important in the policy type of framework to have such scoping</div>









</div></div></div></blockquote><div><br></div></div><div>The framework you're referring to is common and already reusable, it's not a prerogative of Neutron.</div></div></div></div></blockquote><div><br></div></div>



<div>
Are you suggesting that Service Plugins, L3, IPAM etc become individual endpoints, resulting in redundant authentication round-trips for each of the components.</div><div><br></div><div>Wouldn't this result in degraded performance and potential consistency issues?</div>



</div></div></div></blockquote><div><br></div></div><div>The endpoint - in the OpenStack lingo - that exposes the API abstractions (concepts and operations) can be, logically and physically, different from the worker that implements these abstractions; authentication is orthogonal to this and I am not suggesting what you mention.</div>
</div></div></div></blockquote><div><br></div><div>From what I understand, you are saying that the implementation could be done via a mechanism different than a service plugin. Would this be done by implementing the service plugin as a different process? This would imply making changes to the the neutron server - plugin interface. If this is the case, wouldn't it be better to use the existing mechanism to avoid introducing any instability at this stage of the Juno cycle.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">


</div></div></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></div></div>