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

[Liran Schour]

Ben Pfaff <blp at nicira.com> wrote on 01/09/2015 06:55:30 PM:

> From: Ben Pfaff <blp at nicira.com>
> To: Liran Schour/Haifa/IBM at IBMIL
> Cc: dev <dev at openvswitch.org>
> Date: 01/09/2015 06:55 PM
> Subject: Re: OVN: RFC add a new JSON-RPC selective monitoring method
> 
> On Mon, Aug 31, 2015 at 01:19:35PM +0300, Liran Schour wrote:
> > 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)
> 
> Thanks.  I have some comments.
> 
> First, this drops the "columns" member.  Why?  I see no other way to
> specify which columns are monitored.
> 

Will fix that.

> Second, this isn't entirely clear about how to consider the conditions,
> because a condition can be true before a row is modified and false
> afterward, and vice versa.  Presumably, when a row becomes covered by a
> condition (after its initial insertion), or when a row is no longer
> covered by a condition (even though it has not be deleted), the client
> should be notified.
> 

I will define it under the specification of <monitor_select>.

> Third, this may be a good opportunity to fix a design mistake in
> "monitor", which is that it sends too much data when a row is modified:
> it sends both the old and new values for columns that have changed, as
> well as the value of every column that did not change.  I thought that
> would be useful when I originally designed it, but it's proven to just
> waste CPU and memory and bandwidth.
> 

I will include a new version of Update Notification that will describe 
this change.

I will re-write and send the proposal.

Thanks,
- Liran