On Mon, Apr 18, 2016 at 3:27 AM, Jiri Benc <jb...@redhat.com> wrote: > On Fri, 15 Apr 2016 20:36:51 -0700, Jesse Gross wrote: >> I'm not too excited about this. It seems like it would be a regression >> - currently OVSDB allows remote creation of tunnels, so it seems like >> this would break existing setups if it also requires users to >> explicitly create tunnel devices on the host ahead of time. > > It wouldn't break the existing setups, the current code is not going > away. > > However, it wouldn't allow remote creation of tunnels with new features > (like VXLAN-GPE). I don't think it's that bad - we don't support remote > creation of e.g. veth pairs, yet it's common to have them.
I don't really want to have two separate interfaces to create tunnels. I think this would mean that you would need to use OVSDB to configure tunnels on older kernels (which would then use the kernel compat code) and need a script to create tunnel interfaces and add them to OVS on new kernels. (Even on new kernels I don't know how this would interact with OVS tunnel ports that are not of type 'flow'. Would they also use the compat code?) This seems really hard to use in practice and exports many implementation details across the network. Even if we didn't have to worry about any legacy code, I'm not convinced that taking tunnel configuration out of OVSDB is the right thing from the user's perspective. Much of the value of OVS is around programmatic and central control so we should allow that where possible. For example, if a controller starts using a different encapsulation type in a new version or for a different situation, it seems undesirable to require the user to change things on each machine. With regards to veths, in many cases they are used to stitch together different combinations of OVS and bridging, which is something that is itself a pain point and something that I hope will be less necessary in the future. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
