[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

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!
-------------- 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