> 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 >
The framework you're referring to is common and already reusable, it's not a prerogative of Neutron. > > 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. > This is what static or dynamic libraries are for and reused for; I can have a building block and reuse it many times the way I see fit keeping my components' lifecycles separate. > 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. > A next generation services framework is not a prerequisite to integrating two OpenStack projects via REST APIs. I don't see how we would associate the two concepts together. > > >>> >> >> _______________________________________________ >> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
