| Age | Commit message (Collapse) | Author |
|---|
|
The comments and the code didn't match, so make them agree.
|
|
|
|
Now a specific key can be referenced with syntax like
<ref table="Bridge" column="other-config" key="datapath-id"/>.
Also fixes up an existing place that needed this feature already (and had
a typo, too).
|
|
CC: Jeremy Stribling <strib@nicira.com>
|
|
|
|
These will be used for formatting error messages in an upcoming commit.
|
|
This function is not useful inside ovsdb itself but only in the
"test-ovsdb" test program. To avoid the temptation to use it incorrectly
inside ovsdb, this commit moves it into the test program.
|
|
This function took a struct ovsdb_table but only used the 'schema' member.
An upcoming patch needs to parse a column set when only the schema is
available, so to prepare for that this patch changes
ovsdb_column_set_from_json() to only take the schema that it really needs.
|
|
Errors from this function were being ignored, which meant that transactions
could use "mutate" to bypass number-of-elements constraints on sets and
maps. This fixes the problem and adds a test to prevent the problem from
recurring.
Bug #5781.
|
|
|
|
The E-R diagram is illegible when rendered in ASCII, so exclude it from
that version only. The E-R diagram is still included in other versions of
the manpage (e.g. for PostScript output).
|
|
This makes the diagram even more informative.
|
|
|
|
The format of "ovs-dpctl dump-flows" has completely changed since
ovsdbmonitor was written. It seems like no one has tried out ovsdbmonitor
since the rewrite, because it didn't work at all. This commit fixes the
parser.
|
|
I can't figure out where JsonReader and JsonWriter come from. I know that
they must exist, because I (and others) have used ovsdbmonitor before, but
I can't find them now.
Switch to using ovs.json, which is part of Open vSwitch so we know that
it exists. At the same time, we have to start translating the Unicode
strings that ovs.json outputs into standard Python strings; otherwise
the "twisted conch" ssh implementation craps out because it tries to
concatenate this Unicode string with a standard string that contains
non-ASCII characters.
|
|
deamon.man allows the file that is including it to include extra text in
the description of --detach by defining a macro named DD. Only some of the
manpages that included it did this (only those manpages that needed extra
text there). But it's better to be quiet in "man --warnings", so this
defines DD to an empty value in the other manpages that include daemon.man.
Reported by lintian.
|
|
The sparse checker does not like taking sizeof(_Bool). Older versions of
sparse output a hard error ("error: cannot size expression"). Newer
versions output a warning ("warning: expression using sizeof bool"). This
commit avoids the problem by not using sizeof(_Bool) anywhere.
The only place where OVS uses sizeof(_Bool) anyway is in code generated by
the OVSDB IDL. It generates it for populating "optional bool" columns in
the database, that is, columns that are allowed to contain 0 or 1 instances
of a bool. For these columns, it generates code that looks roughly like
this:
row->column = xmalloc(sizeof *row->column);
*row->column = value;
This commit changes these columns from type "bool *" to type "const bool *"
and changes the generated code to:
static const bool true_value = true;
static const bool false_value = false;
row->column = value ? &true_value : &false_value;
which avoids the problem and saves a malloc() call at the same time.
The idltest code had a column with a slightly different type ("0, 1, or
2 bools") that didn't fit the revised pattern and is a fairly stupid type
anyhow, so I just changed it to "0 or 1 bools".
|
|
Found with sparse.
|
|
Found by sparse.
|
|
Previously, if --private-key or another option that requires SSL support
was used, but OVS was built without OpenSSL support, then OVS would fail
with an error message that the specified option was not supported. This
confused users because it made them think that the option had been removed:
http://openvswitch.org/pipermail/discuss/2011-April/005034.html
This commit improves the error message: OVS will now report that it was
built without SSL support. This should be make the problem clear to users.
Reported-by: Aaron Rosen <arosen@clemson.edu>
Feature #5325.
|
|
Until now, it has been the responsibility of an individual daemon to call
die_if_already_running() at an appropriate time. A long time ago, this
had to happen *before* daemonizing, because once the process daemonized
itself there was no way to report failure to the process that originally
started the daemon. With the introduction of daemonize_start(), this is
now possible, but we haven't been taking advantage of it.
Therefore, this commit integrates the die_if_already_running() call into
daemonize_start() and deletes the calls to it from individual daemons.
|
|
When ovsdb-server reads a database file that is corrupted at the
transaction level (that is, the transaction is valid JSON and has the
correct SHA-1 hash, but it does not describe a valid database transaction),
then ovsdb-server should truncate it and overwrite it by valid
transactions. However, until now, it didn't. Instead, it would keep the
invalid transaction and possibly every transaction in the database file
(depending on in what way the transaction was invalid), which would just
cause the same trouble again the next time the database was read.
This fixes the problem. An invalid transaction will be deleted from the
database file at the first write to the database.
Bug #5144.
Bug #5149.
|
|
If there's database corruption then it indicates that something went wrong,
e.g. the machine was powered-off by power failure. It's definitely
something that the admin should know about. This sounds like an error to
me, so use that log level.
|
|
When a strong reference to a non-root table is ephemeral, the database log
can contain inconsistencies. In particular, if the column in question is
the only reference to a row, then the row will be created in one logged
transaction but the reference to it will not be logged (because it is
ephemeral). Thus, any later occurrence of the row later in the log (to
modify it, to delete it, or just to reference it) will yield a transaction
error and reading the database will abort at that point.
This commit fixes the problem by forcing any column with a strong reference
to a non-root table to be persistent.
The change to ovsdb_schema_from_json() looks bigger than it really is: it
just swaps the order of two operations on the schema and updates their
comments. Similarly for the update to ovs.db.DbSchema.__init__().
Bug #5144.
Reported-by: Sujatha Sumanth <ssumanth@nicira.com>
Bug #5149.
Reported-by: Ram Jothikumar <rjothikumar@nicira.com>
|
|
In each of the cases converted here, an shash was used simply to maintain
a set of strings, with the shash_nodes' 'data' values set to NULL. This
commit converts them to use sset instead.
|
|
Reported-by: Paul Ingram <paul@nicira.com>
|
|
In a parallel make, the install-exec-local target runs concurrently with
the creation of the directory that it installs into. Fix the race by
using the install-exec-hook target instead, which runs subsequently to
directory creation.
|
|
Only the time connected (if connected) or disconnected (if disconnected) is
currently reported for each manager. Change to reporting both in seconds since
the last connect and disconnect events respectively. An empty value indicates
no previous connection or disconnection.
This can help diagnose certain connectivity problems, e.g. flapping.
Requested-by: Peter Balland <peter@nicira.com>
Bug #4833.
|
|
This could causes unit tests to fail sometimes.
|
|
|
|
The comment on the n_refs member of struct ovsdb_row says that it does not
count references from a row to itself, but the code didn't implement this
properly. This commit makes the code consistent with the comment.
This does not actually affect any existing OVSDB behavior, because a row's
reference count currently affects only whether it may be deleted, and
references from a row to itself disappear when the row is deleted. But
an upcoming commit will add new uses for a row's reference count, so at
that point it becomes important.
|
|
for_each_txn_row() restricts the txn_rows that its callback may delete.
Until now, this has meant that its callback could not delete any rows
that were created within the transaction being processed. These rows have
txn_rows with null 'old' and nonnull 'new', so to delete them requires
either removing the txn_row entirely (forbidden by for_each_txn_row()) or
clearing its 'new' to null. The latter is forbidden because a txn_row
is not allowed to have both 'old' and 'new' null.
Until now, this has not been a significant restriction, because none of
the processing at transaction commit time required deleting arbitrary rows.
Implementing garbage collection, however, does require this ability, so
this commit makes it possible by eliminating the requirement that at least
'old' or 'new' be nonnull.
|
|
The name 'created' better reflects the actual meaning of this member: in
both ovsdb and ovs-vsctl, it is true if a row has been created with the
symbol's UUID and false otherwise.
|
|
ovsdb_execute_insert() tried to return a helpful error message when there
was a duplicate uuid-name, but ovsdb_execute() (its caller) makes any
parse error override a parse error. Since ovsdb_execute_insert() would
skip parsing the row when the uuid-name was a duplicate, this meant that
the error actually reported would be that "row" was not allowed here, which
wasn't at all helpful (since "row" is in fact mandatory).
This commit clears up the problem by always retrieving the "row" member,
which required a small amount of refactoring, and adds a test.
|
|
Sometimes internal errors are generated based on an originating error. In
these cases we were just throwing this information away. This commit adds
this information to the internal error report so that the error will be
easier to track down.
I haven't actually seen a situation like this come up.
|
|
The "uuid-name" that creates symbols must be an <id> but we weren't
verifying the same constraint on the "named-uuid"s that refer to symbols,
which was a bit confusing in writing transactions by hand. This commit
fixes the inconsistency and updates the SPECS file to clarify that a
named-uuid string has to be an <id>.
|
|
Commit 0b3e7a8b71 (ovsdb-server: Write manager status information to Manager
table.) attempted to provide managers with the ability to debug manager-related
connection problems, but it turns out that reporting "time_in_state" is not
very useful, because the state is constantly changing. What people really want
is the time each manager has been connected or disconnected, depending on the
current connection state.
Replace "time_in_state" key with "time_connected" and "time_disconnected"
keys. Only one exists at a time, and time is in seconds.
Bug #4833.
|
|
The return value isn't interesting here: it will always be 0.
Coverity #10698.
|
|
ovsdb_txn_commit() may return a ovsdb_error structure, which should be
freed by the caller. The only remaining caller that discards the result
is in ovsdb_file_open__(), which this fixes.
Suggested-by: Ben Pfaff <blp@nicira.com>
|
|
Coverity #10726
|
|
There's no indication that "date" is optional in the description of
ovsdb_file_txn_from_json(), and the one caller always passes it in, so
don't bother checking whether it exists.
Coverity #10732
|
|
Coverity #10723
|
|
Coverity #11066
|
|
Reported-by: Peter Balland <peter@nicira.com>
Bug #4698.
|
|
|
|
|
|
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.
|
|
--format=list corresponds to the output format that "ovs-vsctl list" has
always used.
--bare is easier for scripts to parse.
|
|
This makes the table formatting functions available to other programs.
ovs-vsctl will start using it soon on the "list" and "find" commands.
|
|
"warning: 'parse_db_string_column' defined but not used"
This commit fixes the above warning when compiling on systems which
do not have SSL support. It also causes query_db_string() to
always be compiled on these systems as it is not SSL specific and
may be useful in the future.
|
