These commands can be implemented just as well, and in a more
general-purpose way, using the "set", "remove", and "get" commands.
The br-{get,set}-external-ids commands have slightly more specialized
behavior and so we can't drop them (yet).
The upcoming "remove" command for ovs-vsctl wants to try parsing an
argument two different ways. This doesn't work if a parse error always
aborts immediately. This commit fixes the problem, by making a parsing
failure pass up an error for higher layers to deal with instead of aborting
immediately.
This commit should have no user-visible effect.
Before, both "xY_z" and "xy-z" were considered equally good matches for
"xy-z", but obviously the latter is a much better match. This commit fixes
the problem (which was found by inspection).
The new "get", "list", "set", and "add" commands provide lower-level
access to the vswitch database than the other ovs-vsctl commands, but they
are more convenient than using ovsdb-client directly.
This commit deserves several enhancements, but users are clamoring for
some kind of interface, so this is a starting point.
The compiler warns about next_cfg being uninitialized but in the cases
where it is unset we will never reach the point where it is used. This
just sets next_cfg to 0 to stop the whining.
Some systems, such as XenServer, expect that bonds have their own interface.
This commit adds the ability to do that with the "--fake-iface" option
in ovs-vsctl's add-bond command. It also has XenServer's
interface-reconfigure use it.
Part of solution to Bug #2376
ovs-vsctl supports the "--timeout" option, which specifies the amount
of time that the operation is allowed to take before a SIGALRM is
raised. The code that parsed options had a local "timeout" that masked
the global one that was supposed to be set.
When printing the fail-mode, ovs-vsctl would always attempt to print the
top-level one--even if it didn't exist. So, in addition to sometimes
being wrong, it could cause segfaults.
Thanks to Peter Balland for reporting the error.
Bug #2374
Fake bridges can't have controller configuration separate from its
parent, so prevent this from happening.
Thanks to Ben Pfaff for pointing out the problem.
A fake bridge has no br_cfg, so we can't dereference it.
There is a similar problem in cmd_set_controller() and
cmd_del_controller() but this commit does not fix it.
Until now the ovsdb-based vswitch has provided no way to know when it has
finished applying the configuration from the database. This commit
introduces a way:
* The client who wants to wait increments the "next_cfg" column of the
Open_vSwitch record.
* When ovs-vswitchd finishes reconfiguring, it sets the value of the
"cur_cfg" column to that of the "next_cfg" column.
* The client waits until the "cur_cfg" column is at least as great as
the value it set into "next_cfg".
This allows us to drop the 5-second sleep in interface-reconfigure.
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.
