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

Zayats, Michael michael.zayats at hpe.com
Fri Oct 16 07:07:05 UTC 2015

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?


> On Oct 15, 2015, at 11:21 AM, Liran Schour <LIRANS at il.ibm.com> wrote:
> Ben Pfaff <blp at 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 at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev

More information about the dev mailing list