<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 2:21 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div><div><span style="color:rgb(34,34,34)">Adding the GBP extension to Neutron does not change the nature of the</span><br></div></div>
software architecture of Neutron making it more or less monolithic.</blockquote><div><br></div></div><div>I agree with this statement...partially: the way GBP was developed is in accordance to the same principles and architectural choices made for the service plugins and frameworks we have right now, and yes it does not make Neutron more monolithic but certainly not less. These same very principles have unveiled limitations we have realized need to be addressed, according to Neutron's busy agenda. That said, if I were to be given the opportunity to revise some architectural decisions during the new groundbreaking work (regardless of the nature), I would.</div>


<div><br></div><div>For instance, I hate that the service plugins live in the same address space of Neutron Server, I hate that I have one Neutron Server that does L2, L3, IPAM, ...; we could break it down and make sure every entity can have its own lifecycle: we can compose and integrate more easily if we did. Isn't that what years of middleware and distributed systems taught us?</div>


<div><br></div><div>I suggested in the past that GBP would best integrate to Neutron via a stable and RESTful interface, just like any other OpenStack project does. I have been unable to be convinced otherwise, and I would love to be able to change my opinion. </div>
<div class="">

<div></div></div></div></div></div></blockquote><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 class=""><div> <br></div></div></div></div></div></blockquote><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><br></div><div>While the service plugin has scalability issues as pointed above that it resides in neutron server, it is however stable and user configurable and a lot of common code is executed for networking services. So while we make the next generation services framework more distributed and scalable, it is ok to do it under the current framework especially since it has provision for the user to opt in when needed. </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 class=""><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br></blockquote></div></div><br></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>