[openstack-dev] Thought on service plugin architecture (was [Neutron][QoS] Request to be considered for neutron-incubator)

Baohua Yang yangbaohua at gmail.com
Fri Aug 22 09:02:38 UTC 2014


+1
The agent number should be limited restrictly.


On Thu, Aug 21, 2014 at 8:56 AM, loy wolfe <loywolfe at gmail.com> wrote:

>
>
>
> On Wed, Aug 20, 2014 at 7:03 PM, Salvatore Orlando <sorlando at nicira.com>
> wrote:
>
>> As the original thread had a completely different subject, I'm starting a
>> new one here.
>>
>> More specifically the aim of this thread is about:
>> 1) Define when a service is best implemented with a service plugin or
>> with a ML2 driver
>> 2) Discuss how bindings between a "core" resource and the one provided by
>> the service plugin should be exposed at the management plane, implemented
>> at the control plane, and if necessary also at the data plane.
>>
>> Some more comments inline.
>>
>> Salvatore
>>
>>
>>> When a port is created, and it has Qos enforcement thanks to the service
>>> plugin,
>>> let's assume that a ML2 Qos Mech Driver can fetch Qos info and send
>>> them back to the L2 agent.
>>> We would probably need a Qos Agent which communicates with the plugin
>>> through a dedicated topic.
>>>
>>
>> A distinct agent has pro and cons. I think however that we should try and
>> limit the number of agents on the hosts to a minimum. And this minimum in
>> my opinion should be 1! There is already a proposal around a modular agent
>> which should be able of loading modules for handling distinct services. I
>> think that's the best way forward.
>>
>>
>
> +1
> consolidated modular agent can greatly reduce rpc communication with
> plugin, and redundant code . If we can't merge it to a single "Neutron
> agent" now, we can at least merge into two agents: modular L2 agent, and
> modular L3+ agent
>
>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best wishes!
Baohua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140822/775c68fa/attachment.html>


More information about the OpenStack-dev mailing list