Ben Pfaff <b...@nicira.com> wrote on 15/10/2015 02:44:44 AM: > On Wed, Sep 23, 2015 at 08:57:38PM +0300, Liran Schour wrote: > > 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 > > Hi, sorry it took so long to review this. I think it's fine on the > basis of what I was thinking about this before. > > It's probably best to coordinate with Andy on implementation, since I'd > rather end up with two versions of monitor rather than three. I think > that Andy is already writing code, so maybe it would make sense to wait > for him to post his changes before you start on yours (unless you've > already started!). >
OK. Andy, tell me when you post your changes so I will be able to base mine on top of yours. > However, another issue occurs to me now, and I'd like your opinion on it > before we proceed. Once monitor supports a "where" clause, it seems > likely to me that from time to time a client will want to change that > clause on some of the tables it monitors. For example, in OVN a "where" > clause might match rows that are relevant to the logical switches that > are present on a given chassis. If a new VIF comes up, then another > logical switch could then be relevant and need to be added to the > "where" clause. > > One way to implement this kind of a change is for the client to cancel > its previous monitor and create a new one. But that is inefficient > because the server will have to send and the client will have to receive > and parse all of the rows that match the new monitor, instead of just > the rows newly matched by the modified clause. So it would be better to > allow a client to modify a monitor rather than just to create and cancel > them. > > Have you thought about this? > My initial thoughts were that clients (ovn-controllers) can have multiple monitor sessions (e.g. one per logical switch) with a single monitor condition each. Now I agree we should allow the clients to monitor a set of conditions in one session and to be able to modify this set. Therefore I propose to add another request method to the OVSDB protocol called "monitor_cond_change" that will specify the changes on the set of conditions. A simple usage of this new method will be to start a monitor_cond session with empty conditions array by the ovn-controller. When a new VM will be attached a monitor_cond_change will be sent with a condition matching the new logical switch to be monitored and vice versa when detaching VMs from the host. Here is the spec: --- Monitor_cond_change: -------------------- The "monitor_cond_change" request enables a client to change an existing conditional replication of the database by specifying a new set of conditions for each replicated table. The request object has the following members: * "method": "monitor_cond_change" * "params": [<db-name>, <json-value>, <monitor-cond-change-requests>] * "id": <nonnull-json-value> The <json-value> parameter should have a value of an existing conditional monitoring session from this client. The <monitor-cond-change-requests> object maps the name of the table to an array of <monitor-cond-change-request>. Each <monitor-cond-change-request> is an object with the following members: * "added": [<condition>*] new set of conditions to be added to the existing set of conditions for this table. * "removed": [<condition>*] existing conditions to be removed from replication. <condition> is specified in Section 5.1 in the RFC. 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. If initial contents are requested by origin monitor_cond request, <table-updates> will contain any newly matched rows by "added" conditions. If deleted contents are requested by origin monitor request, <table-updates> will contain any matched rows by "removed" conditions. Changes according to the new conditions are automatically sent to the client using the "update" monitor notification (see Section 4.1.6). In case that newly set of conditions is empty, no update notifications will be sent. --- Thanks, - Liran _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
