The OVSDB wire protocol has a "monitor" feature that supports table
replication on a column-by-column basis. This wire protocol in theory
supports replicating a table without replicating any columns in it. In
such a case, the client only tracks the UUIDs of the rows in the table.
However, the ovsdb-server implementation did not support this possibility
properly. This commit fixes the bug.
I'm retaining the "managers" column in the Open_vSwitch table for now, but
I hope that applications transition to using "manager_options" eventually
so that we could drop it.
CC: Andrew Lambeth <wal@nicira.com>
CC: Jeremy Stribling <strib@nicira.com>
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.
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>
Until now, each part of a transaction commit that is interested in whether
a column's value has changed has had to do a comparison of the old and new
values itself. There can be several interested parties per commit
(generally one for file storage and one for each remove OVSDB connection),
so this seems like too much redundancy. This commit adds a bitmap
to struct ovsdb_txn_row that tracks whether a column's value has actually
changed, to reduce this overhead.
As a convenient side effect of doing these checks up front, it then
becomes easily possible to drop txn_rows (and txn_tables and entire txns)
that become no-ops. (This probably fixes bug #2400, which reported that
some no-ops actually report updates over monitors.)
This also adds protocol compatibility to the database itself and to
ovsdb-client. It doesn't actually add multiple database support to
ovsdb-server, since we don't really need that yet.
Some of these are serious leaks, in that they could leak some amount of
memory for every transaction processed by the database server.
Found with valgrind.
Until this commit, ovsdb-server would send off echo requests when the
connection became idle, but then it would terminate the connection when
the reply arrived, because it didn't recognize that it was a reply to its
own request (!).
JSON-RPC requires that "params" be an array, but we weren't observing this
properly in the ovsdb specifications or code.
Thanks to Jeremy Stribling for pointing out the problem.
