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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
