On Fri, Aug 8, 2014 at 2:21 PM, Armando M. <arma...@gmail.com> wrote:
> Adding the GBP extension to Neutron does not change the nature of the >> software architecture of Neutron making it more or less monolithic. > > > 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. > > 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? > > 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. > > > 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 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. >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
