Open Stack

>  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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140808/aa7e4eb4/attachment.html>