I am also very interested in the “where” clause in “monitor” for OpenSwitch use and we intended to propose something similar.
Some questions: What will we do when row A is the only reference to row B and row A doesn’t pass the “where” condition? Will A still be sent? or will B exist in IDL without any reference even though B belongs to non root table? What happens when specific row passes “where” clause, gets sent to the subscriber, and then stops complying to the condition? Will client receive a notification that this row was removed? Should it understand that it’s not a real removal? Will OVSDB-server have to remember whether it synced this row for each subscriber in order to send the right inserted/removed notifications? thanks, Michael > On Oct 15, 2015, at 11:21 AM, Liran Schour <lir...@il.ibm.com> wrote: > > 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
