X-Git-Url: http://git.cascardo.eti.br/?a=blobdiff_plain;f=ovsdb%2Fovsdb-server.1.in;h=6c857294c675a23a4df8bf6f3537d2505294468c;hb=HEAD;hp=0fafc49a9a550e7293cc2a967ae1179726609b80;hpb=d4763d1d4efbbcfd884df2d668980d61ec89d75a;p=cascardo%2Fovs.git

diff --git a/ovsdb/ovsdb-server.1.in b/ovsdb/ovsdb-server.1.in
index 0fafc49a9..6c857294c 100644
--- a/ovsdb/ovsdb-server.1.in
+++ b/ovsdb/ovsdb-server.1.in
@@ -21,6 +21,7 @@ ovsdb\-server \- Open vSwitch database server
 .so lib/vlog-syn.man
 .so lib/ssl-syn.man
 .so lib/ssl-bootstrap-syn.man
+.so lib/ssl-peer-ca-cert-syn.man
 .so lib/unixctl-syn.man
 .so lib/common-syn.man
 .
@@ -111,6 +112,7 @@ as the file name.  (This means that ordinarily there should be at most
 one row in \fItable\fR.)
 .so lib/ssl.man
 .so lib/ssl-bootstrap.man
+.so lib/ssl-peer-ca-cert.man
 .SS "Other Options"
 .so lib/unixctl.man
 .so lib/common.man
@@ -243,6 +245,90 @@ notifications (see below) to the request, it must be unique among all
 active monitors.  \fBovsdb\-server\fR rejects attempt to create two
 monitors with the same identifier.
 .
+.IP "4.1.12. Monitor2"
+A new monitor method added in Open vSwitch version 2.5. Monitor2 allows
+for more efficient update notifications (described below).
+.IP
+The monitor method described in Section 4.1.5 also applies to
+monitor2, with the following exceptions.
+.
+.RS
+.IP \(bu
+RPC request method becomes "monitor2".
+.IP \(bu
+Replay result follows <table-updates2>, described in Section 4.1.13.
+.IP \(bu
+Subsequent changes are sent to the client using the "update2" monitor
+notification, described in Section 4.1.13
+.RE
+.
+.IP
+Both monitor and monitor2 sessions can exist concurrently. However,
+monitor and monitor2 shares the same <json-value> parameter space; it
+must be unique among all monitor and monitor2 sessions.
+.
+.IP "4.1.13. Update2 notification"
+The "update2" notification is sent by the server to the client to report
+changes in tables that are being monitored following a "monitor2" request
+as described above. The notification has the following members:
+.
+.RS
+.nf
+"method": "update2"
+"params": [<json-value>, <table-updates2>]
+"id": null
+.fi
+.RE
+.
+.IP
+The <json-value> in "params" is the same as the value passed as the
+<json-value>  in "params" for the corresponding "monitor" request.
+<table-updates2> is an object that maps from a table name to a <table-update2>.
+A <table-update2> is an object that maps from row's UUID to a <row-update2> object. A <row-update2> is an object with one of the following members:
+.
+.RS
+.IP "\(dqinitial\(dq: <row>"
+present for "initial" updates
+.IP "\(dqinsert\(dq: <row>"
+present for "insert" updates
+.IP "\(dqdelete\(dq: <row>"
+present for "delete" updates
+.IP "\(dqmodify\(dq: <row>"
+present for "modify" updates
+.RE
+.
+.IP
+The format of <row> is described in Section 5.1.
+.
+.IP
+<row> is always a null object for a "delete" update. In "initial" and
+"insert" updates, <row> omits columns whose values equal the default
+value of the column type.
+.
+.IP
+For a "modify" update, <row> contains only the columns that are modified.
+<row> stores the difference between the old and new value for those columns,
+as described below.
+.
+.IP
+For columns with single value, the difference is the value of the new
+column.
+.
+.IP
+The difference between two sets are all elements that only belong
+to one of the sets.
+.
+.IP
+The difference between two maps are all key-value pairs whose keys
+appears in only one of the maps, plus the key-value pairs whose keys
+appear in both maps but with different values.  For the latter
+elements, <row> includes the value from the new column.
+.
+.IP
+Initial views of rows are not presented in update2 notifications,
+but in the response object to the monitor2 request. The formatting of the
+<table-updates2> object, however, is the same in either case.
+.
 .IP "5.1. Notation"
 For <condition>, RFC 7047 only allows the use of \fB!=\fR, \fB==\fR,
 \fBincludes\fR, and \fBexcludes\fR operators with set types.  Open
@@ -251,7 +337,34 @@ vSwitch 2.4 and later extend <condition> to allow the use of \fB<\fR,
 of 0 or 1 integer'' and ``set of 0 or 1 real''.  These conditions
 evaluate to false when the column is empty, and otherwise as described
 in RFC 7047 for integer and real types.
-
+.
+.SH "BUGS"
+.
+In Open vSwitch before version 2.4, when \fBovsdb\-server\fR sent
+JSON-RPC error responses to some requests, it incorrectly formulated
+them with the \fBresult\fR and \fBerror\fR swapped, so that the
+response appeared to indicate success (with a nonsensical result)
+rather than an error.  The requests that suffered from this problem
+were:
+.
+.IP \fBtransact\fR
+.IQ \fBget_schema\fR
+Only if the request names a nonexistent database.
+.IP \fBmonitor\fR
+.IQ \fBlock\fR
+.IQ \fBunlock\fR
+In all error cases.
+.
+.PP
+Of these cases, the only error that a well-written application is
+likely to encounter in practice is \fBmonitor\fR of tables or columns
+that do not exist, in an situation where the application has been
+upgraded but the old database schema is still temporarily in use.  To
+handle this situation gracefully, we recommend that clients should
+treat a \fBmonitor\fR response with a \fBresult\fR that contains an
+\fBerror\fR key-value pair as an error (assuming that the database
+being monitored does not contain a table named \fBerror\fR).
+.
 .SH "SEE ALSO"
 .
 .BR ovsdb\-tool (1).