+++ This bug was initially created as a clone of Bug #1720653 +++ 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.
test on version 2.11.0-26: start time: Mon Jan 13 00:19:22 EST 2020 End time: Mon Jan 13 00:21:29 EST 2020 timer=2:07 test on version 2.11.0-35 start time: Sun Jan 12 23:01:12 EST 2020 End time: Sun Jan 12 23:03:04 EST 2020 timer=1:52 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:0166