[openstack-dev] [Neutron] Too much "shim rest proxy" mechanism drivers in ML2
blak111 at gmail.com
Fri Jun 6 09:06:43 UTC 2014
>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?
I'm not sure I understand what you are advocating removing vs leaving in
the plugin. I know that some of the drivers are used to configure the
physical fabric to push vlans down to the port that the hypervisor is
plugged into and are meant to be used in conjunction with the openvswitch
While it might make sense for the port-level operations to be done at an
agent level, it doesn't work very well if they require a lot of queries to
driver specific DBs. It makes less sense when it comes to network and
subnet-level operations because there isn't really a mapping between a
network and specific agent, so it would just have to be fulfilled by a
random agent which again may require several DB calls back to the central
Could you elaborate a little more on what types of code should be stripped
out of drivers and moved to agents?
On Fri, Jun 6, 2014 at 1:17 AM, henry hly <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.
> Today, there are more and more drivers, supporting all kinds of networking
> hardware and middleware (sdn controller). Unfortunately, they are designed
> exclusively as chimney REST proxies.
> A very general use case of heterogeneous networking: we have OVS
> controlled by ovs agent, and switchs from different vendor, some of them
> are controller by their own driver/agent directly, others are controlled by
> a sdn controller middleware. Can we create a vxlan network, across all
> these sw/hw switchs?
> It's not so easy: neutron ovs use l2 population mech driver, sdn
> controllers have their own population way, today most dedicated switch
> driver can only support vlan. sdn controller people may say: it's ok, just
> put everything under the control of my controller, leaving ml2 plugin as a
> shim rest proxy layer. But, shouldn't Openstack Neutron itself be the first
> class citizen even if there is not controller involved?
> 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? Heterogeneous networking may become easier, while ofagent
> give a good example, it can co-exist with native neutron OVS agent in vxlan
> l2 population. And with the help of coming ML2 agent framework, hardware
> device or middleware controller adaption agent could be more simplified.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev