On Fri, Aug 8, 2014 at 7:13 PM, Armando M. <arma...@gmail.com> wrote:

>
>> On Fri, Aug 8, 2014 at 5:38 PM, Armando M. <arma...@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
>> 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
> 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

Reply via email to