[ovs-dev] [PATCH v6 2/3] ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.

[Ilya Maximets]

On 5/28/20 7:09 PM, Han Zhou wrote:
> 
> 
> On Thu, May 28, 2020 at 5:32 AM Dumitru Ceara <dceara at redhat.com <mailto:dceara at redhat.com>> wrote:
>>
>> Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
>> (i.e., "monitor_cond_since" method) with the initial monitor condition
>> MC1.
>>
>> Assuming the following two transactions are executed on the
>> ovsdb-server:
>> TXN1: "insert record R1 in table T1"
>> TXN2: "insert record R2 in table T2"
>>
>> If the client's monitor condition MC1 for table T2 matches R2 then the
>> client will receive the following update3 message:
>> method="update3", "insert record R2 in table T2", last-txn-id=TXN2
>>
>> At this point, if the presence of the new record R2 in the IDL triggers
>> the client to update its monitor condition to MC2 and add a clause for
>> table T1 which matches R1, a monitor_cond_change message is sent to the
>> server:
>> method="monitor_cond_change", "clauses from MC2"
>>
>> In normal operation the ovsdb-server will reply with a new update3
>> message of the form:
>> method="update3", "insert record R1 in table T1", last-txn-id=TXN2
>>
>> However, if the connection drops in the meantime, this last update might
>> get lost.
>>
>> It might happen that during the reconnect a new transaction happens
>> that modifies the original record R1:
>> TXN3: "modify record R1 in table T1"
>>
>> When the client reconnects, it will try to perform a fast resync by
>> sending:
>> method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
>>
>> Because TXN2 is still in the ovsdb-server transaction history, the
>> server replies with the changes from the most recent transactions only,
>> i.e., TXN3:
>> result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
>>
>> This causes the IDL on the client in to end up in an inconsistent
>> state because it has never seen the update that created R1.
>>
>> Such a scenario is described in:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
>>
>> To avoid this issue, the IDL will now maintain (up to) 3 different
>> types of conditions for each DB table:
>> - new_cond: condition that has been set by the IDL client but has
>>   not yet been sent to the server through monitor_cond_change.
>> - req_cond: condition that has been sent to the server but the reply
>>   acknowledging the change hasn't been received yet.
>> - ack_cond: condition that has been acknowledged by the server.
>>
>> Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
>> disconnect):
>> - if there is a known last_id txn-id the code ensures that new_cond
>>   will contain the most recent condition set by the IDL client
>>   (either req_cond if there was a request in flight, or new_cond
>>   if the IDL client set a condition while the IDL was disconnected)
>> - if there is no known last_id txn-id the code ensures that ack_cond will
>>   contain the most recent conditions set by the IDL client regardless
>>   whether they were acked by the server or not.
>>
>> When monitor_cond_since/monitor_cond requests are sent they will
>> always include ack_cond and if new_cond is not NULL a follow up
>> monitor_cond_change will be generated afterwards.
>>
>> On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
>>
>> This ensures that updates of type "insert" that happened before the last
>> transaction known by the IDL but didn't match old monitor conditions are
>> sent upon reconnect if the monitor condition has changed to include them
>> in the meantime.
>>
>> CC: Han Zhou <hzhou at ovn.org <mailto:hzhou at ovn.org>>
>> Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
>> Signed-off-by: Dumitru Ceara <dceara at redhat.com <mailto:dceara at redhat.com>>
>> ---
>>  lib/ovsdb-idl-provider.h |    8 ++
>>  lib/ovsdb-idl.c          |  167 ++++++++++++++++++++++++++++++++++++++++------
>>  tests/ovsdb-idl.at <http://ovsdb-idl.at>       |   56 +++++++++++++++
>>  3 files changed, 206 insertions(+), 25 deletions(-)

> Acked-by: Han Zhou <hzhou at ovn.org <mailto:hzhou at ovn.org>
Thanks!  Applied to master and backported down to 2.12.

Best regards, Ilya Maximets.