On Wed, Aug 20, 2014 at 7:03 PM, Salvatore Orlando <[email protected]> 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
