Open Stack

On Fri, Apr 10, 2015, at 12:31 AM, Kevin Benton wrote:
> I mentioned this in my email in the previous thread, but I am also
> concerned about the use of the Linux bridge plugin as the default for
> devstack.
> 
> It will reflect poorly on the Neutron project because we are defaulting
> to
> something that gets almost no development effort and that is not even
> gated
> on (other than unit tests). This is a risky move that can damage
> first-time
> users' opinions of the viability of OpenStack. I wouldn't feel confident
> about something that has defaults that could be broken at any time...
> even
> during a release.
> 
> Can someone point me to the list of complaints about OVS? I would rather
> invest time in addressing those issues rather than ignoring everything a
> good chunk of the neutron community has spent significant time on.
As someone that just spent a large chunk of this week debugging OVS in
order to get multinode testing of Neutron with DVR [0] running without
breaking existing multinode testing of nova net with multihost here is
what I have learned.

OVS documentation is terrible. There is no cohesive documentation that
explains the operation and use of OVS to the user. There are dev docs
[1], there are man pages for a large number of ovs-* commands [2], there
are "cookbooks" [3], and there are blog posts from luckier souls than me
that actually got OVS to work [4]. What I would really like to see is a
cohesive set of docs that explains the operation of OVS (please do point
me at them if they exist I just haven't found them).

There are a large number of commands, so far I have found ovs-appctl,
ovs-dpctl, ovs-ofctl, and ovs-vsctl. Unfortunately, as a user I am
unsure what specifically each command exists for. I know they are ovs
related and they control things. Even reading the man pages I am not
quite sure what I would use each of them for. I think this is largely
due to the lack of cohesive documentation that explains things like
datapaths and how ovs-dpctl might be useful to control them.

tcpdump does not work on OVS interfaces. I just about gave up at this
point. To get packet captures I have to set up a veth, add it to the OVS
bridge, then mirror the the OVS interface onto this new port and tcpdump
the other end. This is non trivial [5] and given the lack of docs I
wouldn't expect users to just know how to do this. Also, this isn't a
physical switch in a datacenter. I shouldn't have to pretend I am moving
cables around and setting up a sniffer device. I am running linux I
should be able to just tcpdump a device.

ARP stops working [6]. OVS appears to be intentionally dropping arp who
has requests. A switch without ARP is not useful. (The setup here is an
OVS bridge on one VM connected to an OVS bridge on another VM via GRE
similar to [3], one bridge has ip address 172.24.4.1/23 and the other
has 172.24.4.2/23. Pinging 172.24.4.2 from 172.24.4.1 does not work
because ARP does not work).

This is basically where I am stuck. Armax has been a tremendous amount
of help, but we still don't have this working. I think I would be much
less frustrated if the linux bridge setup that we already have for nova
network testing with multiple routers didn't just work for nova net. Its
easy to understand, you can tcpdump the interfaces, and ARP who has is
properly broadcast to all interfaces on the same l2.

Thats my rant. I do want to stress that I am very interested in making
Neutron DVR testing on multiple nodes work upstream, and I understand
that OVS is likely the way to do this (so please help). I have less of a
fight in the discussion of devstack defaults, but infra is looking at
building a cloud and based on my experiences this week I am a giant -1
on using OVS anywhere in that deployment.
> 
> If OVS really is a non-starter because of lack of tooling and lack of
> deployer experience, we (the neutron community) will need to put
> significantly more efforts into automated testing and feature parity
> (e.g.
> re-implement DVR).

[0] https://review.openstack.org/#/c/171809/
[1] https://github.com/openvswitch/ovs/blob/master/README.md
[2] http://openvswitch.org/support/dist-docs/ovs-dpctl.8.txt
[3] http://openvswitch.org/support/config-cookbooks/port-tunneling/
[4]
http://blog.scottlowe.org/2013/05/07/using-gre-tunnels-with-open-vswitch/
[5] http://www.yet.org/2014/09/openvswitch-troubleshooting/
[6] http://paste.openstack.org/show/201479/