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

Liran Schour LIRANS at il.ibm.com
Thu Oct 15 18:21:15 UTC 2015


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




More information about the dev mailing list