The idea here is that transaction comments get copied to the ovsdb-server's
transaction log, which can then make it clear later why a particular change
was made to the database, to ease debugging.
In general, we don't want ovs-vsctl to wait forever to connect to the
database, as ovs-vsctl is used extensively in init scripts and the
system will not boot. Use a default value of five seconds as a
stop-gap. Eventually, we'll switch to a model of connection attempts,
since using time-based approach is kind of a hack.
This passes at least one test (the one named "add-br a"). It probably
doesn't pass any more than that.
This is *way* not up to my quality standards, but we are in a super hurry
so I'm pushing it anyhow.
Add support to ovs-ofctl for modifying the network source and destination
IP address with the "mod_nw_src" and "mod_nw_dst" actions, respectively.
And support modifying the TCP/UDP source and destination ports with the
"mod_tp_src" and "mod_tp_dst" actions, respectively.
The variable "socket_name" contains the name of the unix domain socket
to be used for communicating with the OVS process. If the target does
not begin with a "/", the socket name is determined based on a pidfile.
A shadow copy of "socket_name" was kept in the block that looks at the
pidfile, which would cause the function-level one to not be set. This
removes that shadow copy.
By default, ovs-openflowd was not listening for any management
connections. Tools such as ovs-ofctl attempt to use a default location
based on the datapath name. This change creates that default listener.
It is inconvenient to type the whole path to the Unix daemon socket when
using ovs-appctl. Allow the name of the daemon to be used instead when
a pidfile exists in the default location, and contact ovs-vswitchd by
default.
Also, the various options for manipulating vlog were invented before the
general-purpose command mechanism existed. Get rid of all of the action
options in favor of just specifying the command to be executed as
non-option arguments.
Finally, there simply wasn't much value in allowing multiple targets or
options to be specified; these variations were never used in practice. So
simplify the interface by making it one target, one action per invocation.
Also, make ovs-vsctl use the same syntax for its --target option.
Based on work by Justin Pettit.
This reverts commit cae7a4b90a55cbfd4cfd23c06f9f09cd429ab4c0.
This commit forced the user to specify an action when deleting a flow,
which is not desirable. The change was not actually needed, as the
buffer is never passed to str_to_flow() in the original code.
This merge took a little bit of care due to two issues:
- Crossport of "interface-reconfigure" fixes from master back to
citrix that had happened and needed to be canceled out of the merge.
- New script "refresh-xs-network-uuids" added on citrix branch that
needed to be moved from /root/vswitch/scripts to
/usr/share/vswitch/scripts.
This changes the interface of each of the command implementations, making
them take the configuration as an argument and return the output. This
will make it easier to support alternate output formats and to execute more
than one command per invocation (both happening in upcoming commits).
The 'bridge' argument to ovs-vsctl's del-port command is only supplied as
a form of error checking. Sometimes the name of the bridge isn't readily
available, so for such situations this commit allows the user to omit the
name of the bridge entirely.
CC: Ian Campbell <Ian.Campbell@citrix.com>
This feature, which has been in ovs-cfg-mod for some time as the "-c"
option, makes it much easier to see what changes ovs-vsctl actually makes
to ovs-vswitchd.conf.
CC: <Ian.Campbell@citrix.com>
The synopsis section of the man page for ovs-appctl incorrectly stated
that the target option takes "pid" as an argument. This commit corrects
that to say "socket".
When the switch is configured to connect to a controller that accepts
connections, waits a few seconds, and then disconnects without setting up
flows, currently this causes "fail-open" to flush the flow table and
stop setting up new flows during the connection duration. This is OK if
it happens once, but it can easily happen every 8 seconds with typical
backoff settings, and that isn't so great.
This commit changes fail-open to only flush the flow table once the switch
appears to have been admitted by the controller, which prevents these
frequent network interruptions.
Thanks to Jesse Gross for especially valuable feedback.
QA notes: Behavior in fail-open and especially behavior with a controller
that rejects the switch after it connects needs to be re-tested. The
ovs-controller --mute switch added by this commit is one simple way to
create such a controller.
CC: Peter Balland <peter@nicira.com>
Bug #1695. Bug #2055.
Dan requested this change to make it less likely that a user encounter a
CA certificate expiring.
For the "citrix" branch instead of "master" in case a customer upgrades
(without generating new CA certificates) away from the beta.
CC: Dan Wendlandt <dan@nicira.com>
Currently ov-vsctl tries to treat /var/run/ovs-vswitchd.*.ctl as a
file/pipe when it is actually a Unix domain socket:
# ovs-vsctl add-br TEST
Traceback (most recent call last):
File "/usr/bin/ovs-vsctl", line 498, in ?
main()
File "/usr/bin/ovs-vsctl", line 493, in main
function(*args)
File "/usr/bin/ovs-vsctl", line 345, in cmd_add_br
cfg_save(cfg, VSWITCHD_CONF)
File "/usr/bin/ovs-vsctl", line 142, in cfg_save
cfg_reload()
File "/usr/bin/ovs-vsctl", line 126, in cfg_reload
f = open(target, "r+")
IOError: [Errno 6] No such device or address: ' '
# ls -l /var/run/ovs-vswitchd.4173.ctl
srw------- 1 root root 0 Sep 14 12:25 /var/run/ovs-vswitchd.4173.ctl
From strace:
open("/var/run/ovs-vswitchd.4173.ctl", O_RDWR|O_LARGEFILE) = -1 ENXIO (No such device or address)
Our test automation needs to be able to validate that a VLAN bridge and
for this I needed two new operations in ovs-vsctl:
* The ability to query the VLAN tag for a bridge.
* The ability to query the 'parent' of a bridge. The parent is the
non-VLAN/untagged bridge with the same physical devices and
could be a bond.
So given xenbr0 (containing eth0) + xapi2 (VLAN 42 on eth0) and xapi1
(containing bond0 == eth2+eth3) + xapi3 (VLAN 23 on the bonded
interface):
[root@warlock ~]# ovs-vsctl br-to-vlan xapi2
42
[root@warlock ~]# ovs-vsctl br-to-vlan xapi3
23
[root@warlock ~]# ovs-vsctl br-to-parent xapi2
xenbr0
[root@warlock ~]# ovs-vsctl br-to-parent xapi3
xapi1
This was a somewhat difficult merge since there was a fair amount of
superficially divergent development on the two branches, especially in the
datapath.
This has been build-tested against XenServer 5.5.0 and XenServer 5.7.0
build 15122. It has been booted and connected to XenCenter on 5.5.0.
The merge revealed a couple of outstanding bugs, which will be fixed on
citrix and then merged back into master.
When ovs-pki is used for CA cert generation, it generates certificates
that are identical except for the public key. If multiple controllers are
their own certificate authorities, the switch will receive multiple CA
certs that are identical other than their key. Unfortunately, OpenSSL
cannot distinguish between them. This is an excerpt of the
SSL_CTX_load_verify_locations function used by vconn-ssl:
Certificate matching is done based on the subject name, the key
identifier (if present), and the serial number as taken from the
certificate to be verified. If these data do not match, the next
certificate will be tried. If a first certificate matching the
parameters is found, the verification process will be performed; no
other certificates for the same parameters will be searched in case of
failure.
To work around this, we add a bit of uniqueness to each certificate. In
this commit, we add the generation time to the subject name. Please note
that the CN field is limited to 64 bytes, so a bit of name compression
needed to take place in order to fit the time.
Bug #1782
When ovs-pki is used for CA cert generation, it generates certificates
that are identical except for the public key. If multiple controllers are
their own certificate authorities, the switch will receive multiple CA
certs that are identical other than their key. Unfortunately, OpenSSL
cannot distinguish between them. This is an excerpt of the
SSL_CTX_load_verify_locations function used by vconn-ssl:
Certificate matching is done based on the subject name, the key
identifier (if present), and the serial number as taken from the
certificate to be verified. If these data do not match, the next
certificate will be tried. If a first certificate matching the
parameters is found, the verification process will be performed; no
other certificates for the same parameters will be searched in case of
failure.
To work around this, we add a bit of uniqueness to each certificate. In
this commit, we add the generation time to the subject name. Please note
that the CN field is limited to 64 bytes, so a bit of name compression
needed to take place in order to fit the time.
Bug #1782
