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
