[ovs-dev] OVN: RFC add a new JSON-RPC selective monitoring method

Liran Schour 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)

monitor_cond:
-------------

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 
of <monitort-cond-request>.

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 
contents are
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 
by <monitor-select>:

  *  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" 
request.
 
  *  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 
the ovsdb-server.



More information about the dev mailing list