Open Stack

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
>> 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 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/20140811/b5321c46/attachment.html>