Perfect. The agent will have all static hooks for the extensions in place, like they are used in todays agents (the modular agent was derived from existing lb agent). The knowledge which concrete extension implementation to chose (e.g. lb) comes from the implementation specific manager class that is required for instantiating the modular agent. So it is ensured that with lb you get the lb extensions, with sriov you get the sriov extensions.
There are no plans to make extensions more "modular" (whatever this means in this context) as well in the first round. But we can discuss for a second stage. Thanks -- Andreas (IRC: scheuran) On Mi, 2015-11-18 at 15:28 +0100, Ihar Hrachyshka wrote: > Andreas Scheuring <scheu...@linux.vnet.ibm.com> wrote: > > > Hi all, > > I wonder if this is somehow in conflict with the modular l2 agent > > approach I'm currently following up for linuxbridge, macvtap and sriov? > > - RFE: [1] > > - Frist patchset [2] > > > > I don't think so, but to be sure I wanted to raise it up. > > I don’t believe it’s in conflict, though generally, I suggest you move > extensions code into modular l2 agent pieces, if possible. We will have > extensions enabled for lb, ovs, and sr-iov the least in Mitaka. > > Ihar > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
