[ovs-dev] OVN: V2 RFC add a new JSON-RPC selective monitoring method

Ben Pfaff blp at nicira.com
Wed Oct 14 23:44:44 UTC 2015

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!).

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

Have you thought about this?



More information about the dev mailing list