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

loy wolfe loywolfe at gmail.com
Thu Aug 21 00:56:54 UTC 2014


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


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140821/c712d4a3/attachment.html>


More information about the OpenStack-dev mailing list