Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.

Bug 1780729

Summary:	measure the time needed by ovn-controller to resync to a new SB db
Product:	Red Hat Enterprise Linux Fast Datapath	Reporter:	Timothy Redaelli <tredaelli>
Component:	openvswitch2.11	Assignee:	lorenzo bianconi <lorenzo.bianconi>
Status:	CLOSED ERRATA	QA Contact:	ying xu <yinxu>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	RHEL 8.0	CC:	ctrautma, jhsiao, jishi, kfida, lorenzo.bianconi, qding, ralongi, tredaelli
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openvswitch2.11-2.11.0-30.el8fdp	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1776883	Environment:
Last Closed:	2020-01-22 04:02:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Timothy Redaelli 2019-12-06 18:10:07 UTC

+++ This bug was initially created as a clone of Bug #1776883 +++

+++ 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.

Comment 2 ying xu 2020-01-14 06:22:39 UTC

test on version 2.11-35
[root@dell-per730-19 qos]# rpm -qa|grep openvs
python3-openvswitch2.11-2.11.0-35.el8fdp.x86_64
kernel-kernel-networking-openvswitch-ovn-qos-1.0-1.noarch
openvswitch2.11-2.11.0-35.el8fdp.x86_64
kernel-kernel-networking-openvswitch-ovn-common-1.0-7.noarch

start time:
Tue Jan 14 01:16:29 EST 2020
end time:
Tue Jan 14 01:17:42 EST 2020

time=01:13

test on version 2.11-26
[root@dell-per730-19 qos]# rpm -qa|grep openvs
python3-openvswitch2.11-2.11.0-26.el8fdp.x86_64
kernel-kernel-networking-openvswitch-ovn-qos-1.0-1.noarch
openvswitch2.11-2.11.0-26.el8fdp.x86_64
kernel-kernel-networking-openvswitch-ovn-common-1.0-7.noarch

start time:
Tue Jan 14 00:43:24 EST 2020
end time:
Tue Jan 14 00:44:45 EST 2020
time=01:21

set verified

Comment 4 errata-xmlrpc 2020-01-22 04:02:49 UTC

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:0171