If sending the transaction fails (jsonrpc_session_send() returns 0),
then we need to transition to TXN_TRY_AGAIN. (Transitioning to
TXN_INCOMPLETE is actually a no-op, because at this point in the code
we are guaranteed to be in that state already.)
Leaving the transaction in TXN_INCOMPLETE causes a segfault later in
ovsdb_idl_txn_destroy() when it calls hmap_remove() on the transaction's
txn_node.
This bug reveals a hole in the ovsdb_idl_txn state machine: destroying
a transaction without committing it or aborting it will cause the same
problem. This problem is *not* fixed by this patch: it really should be
handled by adding a new state TXN_UNCOMMITTED that indicates that the
transaction is not yet committed or aborted. That's too much for this
patch, and doesn't really matter for OVS at the moment since none of its
code paths destroy a transaction without committing or aborting it.
Bug #2435.
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.
The ovs-vsctl "create" command, and perhaps other commands, should print
the UUID of the newly created database row, but until now the IDL has not
provided a way to find that out. This commit adds the ability.
ovs-vsctl wants to use these functions directly, so make them available
through the ovsdb-idl public header instead of only through the private
one.
Also, change the prototypes to make them usable without casts.
The IDL is intended to allow clients easier access to data in the database
by providing an extra layer of abstraction. However, ovs-vsctl needs to
also provide generic access to database tables, rows, and columns, and
until now the IDL has not allowed this. In particular, there was no way
to modify the value of a database column by providing a "struct
ovsdb_datum" with the new value and then have that reflected in the IDL
structs, although the other direction was possible.
This commit fixes that problem, which requires a bit of refactoring of the
IDL layer. It also exposes the interface for iterating through table
records to clients directly, by moving it from the "private" IDL header to
the public one.
If ovsdb_idl_txn_destroy() is called to destroy a transaction before its
reply has been received from the database server, then until now we would
drop the connection to the database when the reply actually arrived,
because we would have no record of that transaction ID any longer.
Notably, ovs-vswitchd does this: it "fires and forgets" database
transactions. (Really, it should not do that, but that's a bigger commit.)
This commit fixes the problem by not dropping the database connection in
such a case.
This fixes an observed problem such that sometimes ovs-vsctl took a long
time to complete, which was because ovs-vswitchd was dropping its
connection to the database and backing off.
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.
If the transaction modified a row and then deleted it, the IDL would
instead mistakenly leave the row entirely untouched.
This commit fixes this bug. It needs a regression test, but this commit
does not add one.
When the IDL was used to insert a row, but all of the new row's columns
were left at the default values, then the IDL would not insert the row at
all.
When the IDL was used to delete one or more rows, and the transaction did
not include any update or insertion operations, the transaction was dropped
entirely.
This commit fixes these two bugs. It needs a regression test, but this
commit does not add one.
Until now, the "set" functions generated by the IDL updated the data in the
database (during commit) but not the data exposed by the IDL in its data
structures. This was just an oversight, so this commit causes the data
exposed by IDL to be updated also.
Our tests only checked references from a table to itself, so of course
there were bugs in references from one table to another. This fixes the
obvious one and adds a test.
