Bug 1036851

Normal operation of the openvswitch-agent results in various warning and error messages being logged to /var/log/openvswitch/ovs-vswitchd.log, which, although not representing actual failures, can cause concern.

For example, setting up the patch port connecting br-int and br-tun results in:

2013-12-02T16:35:45Z|00103|netdev_vport|ERR|patch-tun: patch type requires valid 'peer' argument
2013-12-02T16:35:45Z|00104|bridge|WARN|could not configure network device patch-tun (Invalid argument)
2013-12-02T16:35:45Z|00105|netdev_vport|ERR|patch-tun: patch type requires valid 'peer' argument
2013-12-02T16:35:45Z|00106|bridge|WARN|could not configure network device patch-tun (Invalid argument)
2013-12-02T16:35:45Z|00107|bridge|INFO|bridge br-int: added interface patch-tun on port 1
2013-12-02T16:35:46Z|00108|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device patch-int failed: No such device
2013-12-02T16:35:46Z|00109|dpif|WARN|system@ovs-system: failed to add patch-int as port: No such device
2013-12-02T16:35:46Z|00110|netdev_vport|ERR|patch-int: patch type requires valid 'peer' argument
2013-12-02T16:35:46Z|00111|bridge|WARN|could not configure network device patch-int (Invalid argument)
2013-12-02T16:35:46Z|00112|bridge|INFO|bridge br-tun: added interface patch-int on port 1

And setting up a tunnel port on br-tun results in:

2013-12-02T16:35:48Z|00113|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device gre-1 failed: No such device
2013-12-02T16:35:48Z|00114|dpif|WARN|system@ovs-system: failed to add gre-1 as port: No such device
2013-12-02T16:35:49Z|00115|netdev_vport|ERR|gre-1: gre type requires valid 'remote_ip' argument
2013-12-02T16:35:49Z|00116|bridge|WARN|could not configure network device gre-1 (Invalid argument)
2013-12-02T16:35:49Z|00117|bridge|INFO|bridge br-tun: added interface gre-1 on port 2

These messages seem to be due to the neutron.agent.linux.ovs_lib.add_patch_port() and neutron.agent.linux.ovs_lib.add_tunnel_port() functions setting DB attributes one-by-one, which results in invalid intermediate states. In addition to the noise in the log files, attempts to use the ports while in these intermediate states could result in transient incorrect behavior.

This can be resolved by changing these functions to atomically create and configure the OVS ports using a single ovs-vsctl command, with multiple sub-commands separated by "--" as arguments. This would also have the benefit of reducing the overhead of executing multiple commands via rootwrap when a single command would do.