[openstack-dev] [Neutron][ml2] Too much "shim rest proxy" mechanism drivers in ML2
irenab at mellanox.com
Tue Jun 10 08:57:31 UTC 2014
Please see my comments inline.
From: Luke Gorrie [mailto:luke at tail-f.com]
Sent: Monday, June 09, 2014 12:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][ml2] Too much "shim rest proxy" mechanism drivers in ML2
On 6 June 2014 10:17, henry hly <henry4hly at gmail.com<mailto:henry4hly at gmail.com>> wrote:
ML2 mechanism drivers are becoming another kind of "plugins". Although they can be loaded together, but can not work with each other.
Could we remove all device related adaption(rest/ssh/netconf/of... proxy) from these mechanism driver to the agent side, leaving only necessary code in the plugin?
In the Snabb NFV mech driver [*] we are trying a design that you might find interesting.
We stripped the mech driver down to bare bones and declared that the agent has to access the Neutron configuration independently.
In practice this means that our out-of-tree agent is connecting to Neutron's MySQL database directly instead of being fed config changes by custom sync code in ML2. This means there are very little work for the mech driver to do (in our case check configuration and perform special port binding).
[IrenaB] The DB access approach was previously used by OVS and LinuxBridge Agents and at some point (~Grizzly Release) was changed to use RPC communication. You can see the reasons and design details covered by  and the patch itself in 
We are also trying to avoid running an OVS/LinuxBridge-style agent on the compute hosts in order to keep the code footprint small. I hope we will succeed -- I'd love to hear if somebody else is running "agent-less"? Currently we depend on a really ugly workaround to make VIF binding succeed and we are looking for a clean alternative: https://github.com/lukego/neutron/commit/31d6d0657aeae9fd97a63e4d53da34fb86be92f7
[IrenaB] I think that for “Non SDN Controller” Mechanism Drivers there will be need for some sort of agent to handle port update events even though it might not be required in order to bind the port.
[*] Snabb NFV mech driver code: https://review.openstack.org/95711
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev