[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