[openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward
hemanthraviml at gmail.com
Mon Aug 11 17:40:17 UTC 2014
On Fri, Aug 8, 2014 at 7:13 PM, Armando M. <armamig at gmail.com> wrote:
>> On Fri, Aug 8, 2014 at 5:38 PM, Armando M. <armamig at gmail.com> 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
> 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
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev