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.
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.
