Additional info: We are interested in the time that it takes ovn-controller to resync to a different southbound database with substantially the same content. So for example after creating a lot of logical switches and switch ports like in the scale tests, copy the southbound database file (or create an entirely new one with different switches and ports) and start a new ovsdb-server on a different port on the server. The change ovn- remote in the local vswitch and see how long it takes for ovn- controller to update the flows in OVS based on the new database. Girish said that the buffers that ovn-controller used to download the new database were pretty small and when they bumped the size from IIRC 4k -> 64k the download itself went quite a bit faster. But in the end, it is not clear what the delay from (a) change ovn- remote to (b) OVS flows are synchronized, is and if we need to look into optimizing that.
Hi lorenzo, could you tell us how could we test the bug? Thanks & Best Regards, Jianlin Shi
test on version 2.12-8 start time: Mon Jan 13 03:32:00 EST 2020 end time: Mon Jan 13 03:33:41 EST 2020 time=1:41 test on version 2.12-12 start time: Mon Jan 13 03:07:04 EST 2020 end time: Mon Jan 13 03:08:12 EST 2020 time=1:08 set verified
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:0168