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

[Andy Zhou]

On Wed, Sep 9, 2015 at 3:24 AM, Liran Schour <LIRANS at il.ibm.com> wrote:
> Andy Zhou <azhou at nicira.com> wrote on 08/09/2015 10:42:26 PM:
>
>> From: Andy Zhou <azhou at nicira.com>
>> To: Liran Schour/Haifa/IBM at IBMIL
>> Cc: Ben Pfaff <blp at nicira.com>, dev <dev at openvswitch.org>
>> Date: 08/09/2015 10:42 PM
>> Subject: Re: [ovs-dev] OVN: RFC add a new JSON-RPC selective monitoring
>> method
>>
>> On Mon, Sep 7, 2015 at 1:39 AM, Liran Schour <LIRANS at il.ibm.com> wrote:
>> > Andy Zhou <azhou at nicira.com> wrote on 03/09/2015 10:52:42 PM:
>> >
>> >> On Thu, Sep 3, 2015 at 5:27 AM, Liran Schour <LIRANS at il.ibm.com> wrote:
>> >> > Andy Zhou <azhou at nicira.com> wrote on 01/09/2015 11:15:56 PM:
>> >> >
>> >> >> From: Andy Zhou <azhou at nicira.com>
>> >> >> To: Liran Schour/Haifa/IBM at IBMIL
>> >> >> Cc: Ben Pfaff <blp at nicira.com>, dev <dev at openvswitch.org>
>> >> >> Date: 01/09/2015 11:16 PM
>> >> >> Subject: Re: [ovs-dev] OVN: RFC add a new JSON-RPC selective
>> >> >> monitoring
>> >> >> method
>> >> >>
>> >> >> >
>> >> >> >> 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 am working on patch series that implements this enhancement. My
>> >> >> current plan is to send the RFC changes along with the prototyping
>> >> >> code for review. I am currently making a small change to the
>> >> >> original
>> >> >> monitor message to indicate whether it will accept the new Update
>> >> >> Notification format.  With the proposal of <monitor-cond-request>,
>> >> >> I
>> >> >> think it can be implied with the new message, and much cleaner.
>> >> >>
>> >> >> The details of the new Update Notification is more involved that I
>> >> >> would like to prototype before proposing.
>> >> >>
>> >> >
>> >> > I thought to define a new member called "modified" to monitor-select
>> >> > object
>> >> > to signify that update notification should include only modified
>> >> > columns
>> >> > with their new value only. Client should set to true only one of the
>> >> > members
>> >> > "modify", "modified". If both omitted default behavior is "modify" as
>> >> > it
>> >> > is
>> >> > now. (XOR)
>> >>
>> >> This is an interesting proposal. But I don't think we need the bit for
>> >> the new monitor message.
>> >>
>> >> The new 'modified' only update notification is likely to be
>> >> significantly different than current Update Notification,
>> >> I think it will make sense to add a new message type, say, Update
>> >> Notification2 (V2).
>> >>
>> >> Coming back to the modified bit proposal, I don't think we need this
>> >> extra bit. The monitor-select should accept
>> >> both current Update Notification and V2, assuming both changes are
>> >> made into the same OVS release.
>> >>
>> >> On the other hand, this bit may be useful to be added to the current
>> >> monitor message if we want to continue
>> >> using it after monitor-select being available for modified only
>> >> updates. I currently don't foresee such
>> >> use case.  Do you?
>> >>
>> >> Make sense?
>> >>
>> >
>> > The idea behind the "modified" bit proposal was to leave the current
>> > usage
>> > of the monitor request intact and iteratively change the code onlyin
>> > places
>> > that can make a significant benefit from the new "modified" behavior.
>> The v2 proposal will also leave the monitor request intact.
>>
>> > The Update Notification method can remain as is with a minor change that
>> > defines the behavior under the new "modified" bit. (send only "new"
>> > <row>
>> > that includes only selected modified columns).
>> How would row delete be encoded?
>>
>
> In the proposal that I submitted (V2) row delete remains under the same
> behavior as before. Only modified rows can be treated under the new
> "modified" semantics.

That can be improved. Also for columns that stores maps, we also add,
modify or delete at member level.