Hi Subrahmanyam, The patch was originally implemented by Oleg Bondarev :) > plugin-driver appears to be specific to driver provider That's correct > How does this work with single common agent and many providers? The idea is that the plugin-driver is server-side logic which defines how neutron-server interacts with the device implementing LB. For example, haproxy plugin driver does it by communicating with lbaas-agent via rpc. LBaas-agent has specific driver (device driver) that manages haproxy processes on the host. There could be other device drivers. Using common agent is not required for a plugin-driver.
> Who owns the plugin driver? Usually it's vendor's responsibility to maintain their drivers. Thanks, Eugene. On Thu, Dec 19, 2013 at 3:30 AM, Subrahmanyam Ongole < song...@oneconvergence.com> wrote: > > I was going through the latest common agent patch from Eugene. > plugin-driver appears to be specific to driver provider, for example > haproxy has a plugin driver (in addition to agent driver). How does this > work with single common agent and many providers? Would they need to use a > separate topic? > > Who owns the plugin driver? Is it appliance driver provider (such as > f5/radware for example) or Openstack cloud service provider (such as > Rackspace for example?) > > -- > > Thanks > Subra > (Subrahmanyam Ongole) > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev