On Fri, Aug 8, 2014 at 7:13 PM, Armando M. <[email protected]> wrote:
> >> On Fri, Aug 8, 2014 at 5:38 PM, Armando M. <[email protected]> wrote: >> >>> >>> >>>> 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. >>> >> >> Are you suggesting that Service Plugins, L3, IPAM etc become individual >> endpoints, resulting in redundant authentication round-trips for each of >> the components. >> >> Wouldn't this result in degraded performance and potential consistency >> issues? >> > > The endpoint - in the OpenStack lingo - that exposes the API abstractions > (concepts and operations) can be, logically and physically, different from > the worker that implements these abstractions; authentication is orthogonal > to this and I am not suggesting what you mention. > >From what I understand, you are saying that the implementation could be done via a mechanism different than a service plugin. Would this be done by implementing the service plugin as a different process? This would imply making changes to the the neutron server - plugin interface. If this is the case, wouldn't it be better to use the existing mechanism to avoid introducing any instability at this stage of the Juno cycle. > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
