15:07 <racosta> Hi imaximets, how are you?

15:08 <racosta> I found an issue with deleting datapath_binding row but I don't know how to solve it without touching ovn-sb.ovsschema

15:08 <imaximets> Hi

15:08 <imaximets> What's the issue?

15:09 <racosta> Basically, since the tunney_key is updated when we create a transit-switch, the deletion process fail when we have ovsdbapp clients monitoring the Datapath_Binding table

15:10 <racosta> The tunnel_key is index of this table: "indexes": [["tunnel_key"]],

15:12 <racosta> I see something like this in the log of the app connected to SB-DB via ovsdbapp: "2024-05-27 08:31:01.380 13427 ERROR ovsdbapp.backend.ovs_idl.connection [-] Datapath_Binding(uuid=UUID('2c737e09-7b76-4c7f-8855-b25d0096fe10'), tunnel_key=16711682, load_balancers=[], external_ids={}) not in list: ValueError: Datapath_Binding(uuid=UUID('2c737e09-7b76-4c7f-8855-b25d0096fe10'), tunnel_key=16711682, load_balancers=[], external_ids={})

15:12 <racosta> not in list"

15:13 <racosta> I removed the index from the Datapath_Binding table and the error stopped...

15:13 <racosta> Do you have any ideas to solve it without changing the DB schema?

15:17 <imaximets> It sounds like ovsdbapp is trying to remove an element from a local cache that is not there. Doesn't sound like some issue in ovsdbapp rather in a database.

15:17 <imaximets> Do you know what ovsdbapp is doing?

15:18 <imaximets> s/Doesn't sound/Sounds like/ :)

15:19 <imaximets> Schema change might have just forced ovsdbapp to drop and re-create the cache.

15:22 <racosta> I put some debugs in the ovsdbapp connection backend and I see that the deletion is triggering this exception: https://github.com/openstack/ovsdbapp/blob/bccbf70dfe2f8e02c3b5aa82ba1557a35c89f62f/ovsdbapp/backend/ovs_idl/connection.py#L108

15:26 <racosta> I imagine that the problem is not related to the local cache because I restart the process to perform a row sync and it still shows an error when deleting.

15:34 <imaximets> Does this datapath binding exist in the database?

15:36 <racosta> Yes, the row exists and was updated with the UPDATE for the new tunnel_key...

15:38 <imaximets> Does it complain about the old or a new tunnel key?

15:39 <racosta> imaximets, please take a look at this example: https://paste.openstack.org/show/bzmaQ6DCLGBybOEtx9C8/

15:40 <racosta> The Datapath_binding row 2c737e09-7b76-4c7f-8855-b25d0096fe10 is created, updated with the new tunnel_key... and then deleted when I type the ts-del command...

15:52 <racosta> imaximets, a new example including the OVSDB transactions: https://paste.openstack.org/show/bqLA7nxfk2C6loD5YlY1/

15:53 <imaximets> racosta, hmm, I think python-idl is missing the index update when indexed columns change.

15:55 <racosta> yep, it probably expects the table indexes not to change.

15:57 <racosta> This issue affects neutron-server, neutron-ovn-metadata-agent, and everyone using python-idl, when the tunnel_key is updated and then deleted.

15:58 <imaximets> Yeah, it will affect everyone...

15:58 <imaximets> *does

15:59 <racosta> Do you think this should be fixed on the python-idl side or in the OVN SB-DB schma db so as not to index this table by tunnel_key?

16:00 <imaximets> It must be fixed in python-idl. Database and the schema are correct.

16:01 <imaximets> The following may work as a quick'n'dirty solution: https://paste.openstack.org/show/bkxnvMPl8BlECgQlQIvg/

16:01 <imaximets> but it needs refinement.

16:03 <imaximets> racosta, could you send a report to ovs-discuss? I'll work on a proper patch for the idl.

16:03 <racosta> Sure, thank you so much!

16:04 <imaximets> Np. Thanks!