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

Liran Schour LIRANS at il.ibm.com
Wed Sep 23 17:57:38 UTC 2015


Here is an update for the proposed OVSDB protocol specification (RFC 
7047)change suggested for overcoming OVN scalability issues by allowing 
clients to monitor only rows that meet specific criteria 
(http://openvswitch.org/pipermail/dev/2015-August/059149.html)

Original proposal (v1): 
http://openvswitch.org/pipermail/dev/2015-August/059441.html
Discussion: 
http://openvswitch.org/pipermail/dev/2015-September/059681.html

Changes v1 -> v2:
   * Add "columns" member to <monitor-cond> request object to specify 
which columns should be monitored
   * Clarify behavior when a row modification matches monitored conditions
   * Add "modified" member to <monitor-select> object to specify sending 
only changed columns as part of update notification
-----

Updated proposal (v2):
----------------------
monitor_cond:
-------------

The "monitor_cond" request enables a client to replicate subsets of tables 
within an OVSDB database by requesting notifications of changes to rows 
matching all the conditions specified in "where" by receiving the 
specified contents of these rows when table updates occur.

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:
   * "columns": [<column>*]            optional
   * "where": [<condition>*]           optional
   * "select": <monitor-select>        optional

The columns, if present, define the columns within the table to be 
monitored that match conditions. What happens if not present?

<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
* "modified": <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. 
(should we specify a separate "monitor_cond_cancel"?)

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 original 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 or for rows 
modified in the table so that their old version does not match the 
condition and new version does. (new row in the client's replica table)
 
  *  If "delete" is omitted or true, "update" notifications are sent for 
rows deleted from the table that match conditions or for rows modified in 
the table so that their old version does match the conditions and new 
version does not. (deleted row in the client's replica)
 
  *  If "modify" is omitted or true, "update" notifications are sent 
whenever a row in the table that matches conditions in both old and new 
version is modified.

  *  If "modified" is true, "update" notifications are sent whenever a row 
in the table that matches conditions is modified, similarly for the 
"modify" case; the difference is that in this case only new version of 
modified columns are sent.

Client may set exclusively "modify" or "modified" to true but not set both 
to true.

Update Notification

The "update" notification is sent by the server to the client to report 
changes in tables that are being monitored following a "monitor" request 
or "monitor_cond" request as described above.  The notification has the 
following members:

   *  "method": "update"
   *  "params": [<json-value>, <table-updates>]
   *  "id": null

The <json-value> in "params" is the same as the value passed as the 
<json-value> in "params" for the corresponding "monitor" or "moitor_cond" 
request. <table-updates> is an object that maps from a table name to a 
<table-update>.  A <table-update> is an object that maps from the row's 
UUID to a <row-update> object.  A <row-update> is an object with the 
following members:

    "old": <row>   present for "delete" and "modify" updates
    "new": <row>   present for "initial", "insert", "modify" and 
"modified" updates

The format of <row> is described in Section 5.1.

Each table in which one or more rows has changed (or whose initial view is 
being presented) is represented in <table-updates>.  Each row that has 
changed (or whose initial view is being presented) is represented in its 
<table-update> as a member with its name taken from the row's "_uuid" 
member.  The corresponding value is a <row-update>:

   *  The "old" member is present for "delete" and "modify" updates. For 
"delete" updates, each monitored column is included. For "modify" updates, 
the prior value of each monitored column whose value has changed is 
included (monitored columns that have not changed are represented in 
"new").

   *  The "new" member is present for "initial", "insert", "modify" and 
"modified" updates. For "initial" and "insert" updates, each monitored 
column is included. For "modify" updates, the new value of each monitored 
column is included. For "modified" updates, the new value of each 
monitored column that has been changed is included.

Note that initial views of rows are not presented in update notifications, 
but in the response object to the monitor request. The formatting of the 
<table-updates> object, however, is the same in either case.



More information about the dev mailing list