From early days, Nicira used the --with-build-number option to configure to
stamp our internal builds. We've since switched to another scheme, so
this option is obsolete.
Good riddance.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This makes ovsdb-tool easier to use in the common case.
Feature #7756.
Requested-by: Reid Price <reid@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Now output that formerly looked like ["map", [["key1", "value1"], ["key2",
"value2"]]] is printed like {key1=value1, key2=value2}, which I find easier
to read.
The "show-log" command tries to give names to the rows to make it easier to
understand what's going on, but it's still important to see at least
partial UUIDs so that one can search the output for references to the rows
by UUID.
This provides clients a way to coordinate their access to the database.
This is a voluntary, not mandatory, locking protocols, that is, clients
are not prevented from modifying the database unless they cooperate with
the locking protocol. It is also not related to any of the ACID properties
of database transactions. It is strictly a way for clients to coordinate
among themselves.
The following commit will introduce one user.
This new function saves reading the whole database when only the schema is
of interest. This commit adapts ovsdb-tool to use it for the "db-version"
command. Upcoming commits will introduce another caller.
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
Since the timeval module now initializes itself on-demand, there is no
longer any need to initialize it explicitly, or to provide an interface to
do so.
Until now, "ovsdb-tool convert" and "ovsdb-tool compact" were willing to
wait an arbitrarily long time to get a lock on the database or on a
temporary file. In practice, though, the program most likely to have the
lock is ovsdb-server, which is not a transient process, and thus
ovsdb-tool will likely wait indefinitely if it waits at all.
This commit changes these ovsdb-tool commands so that they won't wait at
all if some other program has the lock. (The other commands already had
this behavior.)
As a side effect, this change fixes the behavior of
"/etc/init.d/openvswitch start" when Open vSwitch was already running.
Previously, it would hang waiting for "ovsdb-tool convert" to finish.
Now, it completes quickly with an error.
CC: Reid Price <reid@nicira.com>
Bug #2864.
If the database grows fairly large, and we've written a fair number of
transactions to it, and it's been a while since the database was compacted,
then (after the next commit) compact the database.
Also, compact the database online if the "ovsdb-server/compact" command is
issued via unixctl. I suspect that this feature will rarely if ever be
used in practice, but it's easier to test than compacting automatically.
Bug #2391.
This "can't happen" normally, but it will if you monkey with the OVSDB
file by hand such that a row that gets deleted never actually existed in
the db.
"ovsdb-tool compact SRC DST" and "ovsdb-tool convert SRC SCHEMA DST" do not
need to lock SRC, because they do not modify it.
Reported-by: Justin Pettit <jpettit@nicira.com>
The current callers of ovsdb_log_open() always want to lock the file if
they are accessing it for read/write access. An upcoming commit will add
a new caller that does not fit this model (it wants to lock the file
across a wider region) and so the caller should be able to choose whether
to do locking. This commit adds that ability.
Also, get rid of the use of <fcntl.h> flags to choose the open mode, which
has always seemed somewhat crude and which this change would make even
cruder.
An upcoming commit will add support for replicating tables across JSON-RPC
connection. As a prerequisite ovsdb itself must support basic replication.
This commit adds that support and then reimplements the ovsdb file storage
in terms of that replication.
