Until now, "monitor" has only allowed the client to choose the kinds of
changes that will be monitored on a per-table basis. However, it makes
sense to be able to choose operations on a per-column basis. The
immediate need for this is to make sure that the final statistics of
deleted Interface records are known at time of deletion, even though the
intermediate values of the statistics are not important.
CC: Jeremy Stribling <strib@nicira.com>
This code assumed that the types of operations that were selected were
default-off, so it only added JSON to the query to turn on the ones that
were wanted, but in fact they are default-on, so this commit changes it
to add JSON for each possible operation type.
RFC 4627 (which defines JSON) says:
The names within an object SHOULD be unique.
In my view, this means that the treatment of duplicate names within a
JSON object is more or less up to the implementation. Until now, the OVS
JSON parser has dealt with duplicates fairly badly: they all get shoved
into the hash table and you get one or the other value semi-randomly
(typically the one added later). This commit makes the behavior
predictable: old values are deleted and replaced by newer values.
By breaking out the hash calculation we can enable operations that need
to do both to avoid duplicating the hash calculations. A following commit
will add such an operation.
Without this setting, the certificate authorities that ovs-pki creates will
not allow two switches or two controllers to have the same name. This
causes problem in testing, since it's often convenient to test with short,
common names like "tmp".
(If you need to fix a PKI that you already created, in addition to
modifying ca.cnf you will need to make the same change to index.txt.attr.)
CC: Pierre Ettori <pettori@nicira.com>
The wait-until command to be added to ovs-vsctl in an upcoming commit
doesn't really want to wait for partial matches: if I'm waiting for br1
to be created I really don't want to be fooled by br10. So this commit
adds infrastructure to avoid such partial matches.
The wait-until command to be added in an upcoming commit needs to support
!=, <, >, <=, and >= operators in addition to =, so this commit adds that
infrastructure.
The "wait-until" command to be introduced in an upcoming commit needs to
be able to tell the ovs-vsctl main loop to try again later, since the
condition that it is looking for has not yet been satisfied. This commit
adds the infrastructure for this. (It's being broken out into a separate
commit because it modifies scattered code in ovs-vsctl.c and thus might
be easier to review this way.)
A number of the init scripts assumed that the package name was the same
as the binary, which is not always true. This fixes those issues as
well as some incorrect names in usage messages.
Reported-by: Ram Jothikumar <rjothikumar@nicira.com>
Open vSwitch has always "normalized" flows, that is, zeroed out fields that
are wildcarded or that otherwise cannot affect whether a packet actually
matches the flow. But until now it has done so silently, which prevents
the authors of controllers from learning what is happening and makes it
less likely that they will update code on their end. This commit makes
OVS log when normalization changes a flow.
Suggested by partner.
Commit 823c5699 "interface-reconfigure: callout to datapath backend class
method on rewrite" changed "interface-reconfigure rewrite" to update
bridge external-ids in the vswitch database. But this had the side effect
of causing errors at system shutdown, since ovsdb-server gets shut down
before the rewrite action is called. This commit fixes the problem by
skipping the update if the database socket does not exist. (It's just
fine to skip the update, since the external-ids will be re-set the next
time the system boots anyhow.)
This commit fixed the problem on 5.6.810-34773p for me. I don't see the
problem at all on 5.5.0. Presumably system shutdown order has changed.
NIC-136.
CC: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
interface-reconfigure is never explicitly called to down a bond master.
However, when it is called to up a slave it is implicit that we are
destroying the master. The "bridge" version of interface-reconfigure
always "ifdown"s the bond master in such a case, but until now the
"vswitch" version has not done so. Usually, it doesn't matter, because
the bond master network device disappears when the slave is brought up,
but one case was missed: for a bond master with an IP address obtained
via DHCP, the dhclient process needs to be killed, and we were not doing
it. This commit starts doing it (by invoking ifdown on the bond master).
The dhclient process that hangs around doesn't cause problems until the
bond master is brought back up, at which point "ifup" fails because it
refuses to start another dhclient for the same interface.
The converse behavior is also important; that is, when a bond PIF is
brought up, interface-reconfigure is expected to implicitly take down its
slave PIFs. My testing (on 5.5.0) shows that this behavior is already
correct. At any rate, this commit does not change that behavior.
Bug #2668.
Bug #2734.
Signed-off-by: Ben Pfaff <blp@nicira.com>
In glibc, "timer_t" is a "void *" that appears to point into malloc()'d
memory. By throwing it away entirely, we leak it, which makes valgrind
complain. We really don't ever care to use the timer object again, but
we can't destroy it without stopping the periodic timer. So make it
static to avoid a warning from Valgrind.
linux/highmem.h should be included rather than asm/highmem.h,
otherwise openvswitch_mod cannot resolve kmap and kunmap on some arch.
Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
Commit cde3f1 "ovsdb-idl: Drop unnecessary allocation from
ovsdb_idl_txn_insert()." does lazy allocation of row->written
on the assumption that ovsdb_idl_txn_write() will handle it.
However, this isn't the case for empty rows created by something
like "ovs-vsctl init" so add a check before reading the bitfield.
I noticed that when I run "make check" inside an Emacs compile-mode buffer,
the "daemon --detach closes standard fds" and "daemon --detach --monitor closes
standard fds" tests failed. Investigation showed that Emacs ignores
SIGPIPE in the compile subprocess, which caused the "yes" process in these
tests to emit the message "yes: Broken pipe" and exit with status 1 instead
of dying from SIGPIPE.
This commit changes these tests to allow either behavior.
Logging a few messages about a failed connection every few seconds for
every bridge is too much. This just logs failed connection messages for a
few attempts, then shuts them off until something changes.
Bug #2610.
While I was looking at the rconn code for connection backoff and retry, I
noticed that ovs-vswitchd was logging the following on each connection
attempt:
Jun 11 15:17:41|00020|vconn_stream|ERR|send: Connection refused
The "send:" part didn't make much sense. The configured controller was not
actually running, so the vconn code should not have been able to connect
at all, so the message should have been about a connection failing, not
about sending on a completed connection failing.
Investigation showed that different parts of the library have different
ideas about return value semantics. vconn_open() and stream_open() both
return 0 if a connection succeeded or if one is in progress, but some of
its callers thought that it returned 0 if the connection succeeded and
EAGAIN if the connection was in progress. This commit fixes up the callers
that had the wrong idea, by making them instead all vconn_connect() or
stream_connect() to determine whether the connection is complete.
Before, it was possible for records in the configuration database to
disappear, so all of the ovsrec pointers inside bridge structures had
comments cautioning against their use except during reconfiguration. But
now that the bridge has direct control over when ovsdb_idl_run() is called,
it can ensure that bridge_reconfigure() is always called immediately
whenever the IDL data structures change. That means that we can use the
ovsrec configuration at any time after the reconfiguration process
initializes them, not just during reconfiguration.
Until now, the ovs-vswitchd main loop has managed the connection to the
database. This worked adequately until now, but upcoming patches will tie
the bridge code more tightly to the database, which means that the bridge
needs more control over interaction with the database connection and thus
that it is better for the bridge to handle that connection itself. This
commit makes the latter change, moving the database interaction from the
ovs-vswitchd main loop into bridge.c.
Generated <prefix>_<struct>_parse_<column> functions did not allocate
enough memory for the "value" array, because code that should have said,
e.g.:
row->value_options = xmalloc(datum->n * sizeof *row->value_options);
actually said:
row->value_options = xmalloc(datum->n * sizeof row->value_options);
This fixes the problem. I also checked that the same problem didn't occur
elsewhere in the generated code.
(This would be a fairly serious bug fix, because without it reads and
writes beyond the end of allocated memory would be almost inevitable,
except that every existing map has string values, and sizeof(char*)
== sizeof(char**) on any sane system.)
Sometimes seeing a little bit of SSL protocol information can be valuable
in debugging connection problems. With this commit, setting the stream_ssl
logging module to DBG level will cause basic SSL handshake information to
be logged for new connections.
DarkBls <darkbls@yahoo.com> had the idea that a single ovsdb-server could
be used to serve configuration details across the network to multiple
remote ovs-vswitchd instances. This doesn't work, but the documentation
didn't spell it out. This commit should help.
Commit 97f7803 made this test nondeterministic: depending on the ordering
of the random row UUIDs, the error message might mention one of two
different nonexistent rows that are referenced. This commit fixes the
problem by accepting either one of the two correct rows.
Previous related fixes took a different approach, of instead making the
test deterministic. But now I think that that is not as good an idea,
because we need to be able to test that OVSDB works whether the query is
deterministic or not.
(Of course, every OVSDB test is nondeterministic, since the UUIDs are
random. This test was just more nondeterministic than most.)
