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