Older versions of Open vSwitch supported a management protocol based on
OpenFlow message framing. The current Open vSwitch instead uses the
OVSDB protocol for the same purposes. We don't plan to support this older
protocol any longer, so this commit deletes support.
This commit also deletes the management_id column from the vswitch's
database schema. The management_id was used by the older management
protocol to match up OpenFlow switch connections to management connections,
but the current implementation instead matches up connections based on
the datapath IDs exported by the configuration database. In fact, the
OpenFlow connections had no way to actually export the management ID, so
this just deletes code that was essentially without function anyhow.
Until now, all the ovs-vsctl commands have had no need to look at the
results of the database transaction. However, to print the UUID of newly
inserted database records, they do need to do this.
This commit refactors ovs-vsctl in preparation for adding this ability.
Openflowd had been a bit neglected as changes were made to the dpif
and netdev interfaces over time. This brings it up to date with all
the latest changes.
This brings over some features that were added to the netdev interface,
most notably the separation between the name and the type. In addition
to being cleaner, this also avoids problems where it is expected that
the local port has the same name as the datapath.
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).
When --monitor is used, administrators sometimes become confused about the
presence of two copies of each process. This commit attempts to clarify
the situation by making the monitoring process change its process name, as
seen in /proc/$pid/cmdline and in "ps", to clearly indicate what is going
on.
CC: Dan Wendlandt <dan@nicira.com>
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.
No conflicts, but lib/dpif.c needed a few changes since struct dpif's
member "class" was renamed to "dpif_class" in master since sflow was
branched off.
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.
Until now, fatal_signal_fork() has simply disabled all the fatal signal
callback hooks. This worked fine, because a daemon process forked only
once and the parent didn't do much before it exited.
But upcoming commits will introduce a --monitor option, which requires
processes to fork multiple times. Sometimes the parent process will fork,
then run for a while, then fork again. It's not good to disable the
hooks in the child process in such a case, because that prevents e.g.
pidfiles from being removed at the child's exit.
So this commit changes the semantics of fatal_signal_fork() to just
clearing out hooks. After hooks are cleared, new hooks can be added and
will be executed on process termination in the usual way.
This commit also introduces a cancellation callback function so that a
canceled hook can free resources.
This builds on earlier work that implemented netdev object refcounting.
However, rather than requiring explicit create and destroy calls,
these operations are now performed automatically based on the referenece
count. This is important because in certain situations it is not
possible to know whether a netdev has already been created. A
workaround existed (which looked fairly similar to this paradigm) but
introduced it's own issues. This simplifies and unifies the API.
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
This module, which catches segmentation faults and prints a backtrace
before exiting, was useful for a while, but I believe that it has now
outlived its purpose. It is altogether better to have a core dump from
which one can extract much more information than a usually-poor backtrace,
and core dumps are much better integrated into a typical Unix system.
In addition, the "fault" module was of course not all that portable.
This reduces the amount of redundancy in the source tree, by making all of
the current implementations of a vconn simply delegate to the "stream"
abstraction.
Rather than running signal hooks directly from the actual signal
handler, simply record the fact that the signal occured and run
the hook next time around the poll loop. This allows significantly
more freedom as to what can actually be done in the signal hooks.
The ovs-discover, ovs-dpctl, and ovs-ofctl man pages indicated that they
supported extended vlog options (e.g., --log-file), but they actually
did not. This commit adds them.
Reported by Tetsuo NAKAGAWA <nakagawa@mxc.nes.nec.co.jp>
At one point Nicira had deployment plans for which adding a remote command
execution feature to the OpenFlow stack made a lot of sense. We no longer
have those plans, as far as I know, and leaving the feature in seems like
a huge potential security hole. So this commit blows away the entire
feature.
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.
There are conflicting pressures in startup of a daemon process:
* The parent process should exit with an error code if the daemon
cannot start up successfully.
* Some startup actions must be performed in the child process, not in
the parent. The most obvious of these are file locking, since
child processes do not inherit locks, and anything that requires
knowing the child process's PID (e.g. unixctl sockets).
Until now, this conflict has usually been handled by giving up part of the
first property, i.e. in some cases the parent process would exit
successfully and the child immediately afterward exit with a failure code.
This commit introduces a better approach, by allowing daemons to perform
startup work in the child and only then signal the parent that they have
successfully started. If the child instead exits without signaling
success, the parent passes this exit code along to its own parent.
This commit also modifies the daemons that can usefully take advantage of
this new feature to do so.
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.
