This makes it easy to create a bunch of records that are all related to
each other in a single ovs-vsctl invocation. It adds an example to the
ovs-vsctl manpage.
Before OVSDB was adopted in the vswitch, bridge ioctls were synchronous.
That is, an operation that, say, creates a new bridge was guaranteed to
have completed before brcompatd returned a success result to the kernel.
When OVSDB was adopted, however, we failed to maintain this property.
Instead, bridge creation (etc.) only happened some time after the return
value was passed back to the kernel. This causes a race condition against
software that creates or deletes bridges or ports and expects that the
operation is completed synchronously.
This commit restores the synchronous behavior.
Bug #2443.
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.
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.
