+1 The agent number should be limited restrictly.
On Thu, Aug 21, 2014 at 8:56 AM, loy wolfe <[email protected]> wrote: > > > > 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 > > -- Best wishes! Baohua
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
