[ovs-dev] OVN: RFC add a new JSON-RPC selective monitoring method
LIRANS at il.ibm.com
Mon Aug 31 10:19:35 UTC 2015
Following the discussion on overcoming OVN scalability issues by allowing
clients to monitor only rows that meet specific criteria
(http://openvswitch.org/pipermail/dev/2015-August/059149.html), I propose
to amend the OVSDB protocol specification (RFC 7047).
Proposed amendment is to define a new monitor method, monitor_cond, for
specifying monitoring conditions. Adding a new method allows keeping all
of the existing client code intact, replacing code only in places that can
benefit from this new method (e.g. in ovn-controller).
Below is the description for a new JSON-RPC monitor_cond method to be
added to the OVSDB protocol. (All references are to RFC 7047)
The "monitor_cond" request enables a client to replicate subsets of tables
within an OVSDB database by requesting notifications of changes to those
rows in the table that match all the conditions specified in "where" by
receiving these rows.
The request object has the following members:
* "method": "monitor_cond"
* "params": [<db-name>, <json-value>, <monitor-cond-requests>]
* "id": <nonnull-json-value>
The <json-value> parameter is used to match subsequent update
notifications (see below) to this request.
The <monitor-cond-requests> object maps the name of the table to an array
Each <monitor-cond-request> is an object with the following members:
* "where": [<condition>*] optional
* "select": <monitor-select> optional
<condition> is specified in Section 5.1 in the RFC
<monitor-select> is an object with the following members:
* "initial": <boolean> optional
* "insert": <boolean> optional
* "delete": <boolean> optional
* "modify": <boolean> optional
The contents of this object specify how the columns or table are to be
monitored, as explained
in more detail below.
The response object has the following members:
* "result": <table-updates>
* "error": null
* "id": same "id" as request
The <table-updates> object is described in detail in Section 4.1.6. It
contains the contents of
the tables for which "initial" rows are selected. If no tables' initial
requested, then "result" is an empty object.
Subsequently, when changes to a specified table that match all the
conditions in monitor-cond-request are committed, the changes are
automatically sent to the client using the "update" monitor notification
(see Section 4.1.6). This monitoring persists until the JSON-RPC session
terminates or until the client sends a "monitor_cancel" JSON-RPC request.
Each <monitor-cond-request> specifies one or more conditions and the
manner in which the rows
that match the conditions are to be monitored. The circumstances in which
an "update" notification is sent for a row within the table are determined
* If "initial" is omitted or true, every row in the table that matches
the conditions is sent as part of the response to the "monitor_cond"
* If "insert" is omitted or true, "update" notifications are sent for
rows newly inserted into the table that match conditions.
* If "delete" is omitted or true, "update" notifications are sent for
rows deleted from the table that match conditions.
* If "modify" is omitted or true, "update" notifications are sent
whenever a row in the table that matches conditions is modified.
I send this specification for review.
Next step will be starting a design discussion for implementing this in
More information about the dev