<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 class=""><div class="h5"><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>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> <br></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"> It<br>
fulfills a gap that is currently present in the Neutron API, namely -<br>
to complement the current imperative abstractions with a app<br>
-developer/deployer friendly declarative abstraction [1]. To<br>
reiterate, it has been proposed as an “extension”, and not a<br>
replacement of the core abstractions or the way those are consumed. </blockquote><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">

If<br>
this is understood and interpreted correctly, I doubt that there<br>
should be reason for concern.<br><br></blockquote><div> </div><div>I never said that GBP did (mean to replace the core abstractions): I am talking purely architecture and system integration. Not sure if this statement is directed to my comment.<br>

</div></div><br></div></div>