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

Bug 1803840

Summary:	[OVN][QOS] qos rows not created on network or port qos policy
Product:	Red Hat OpenStack	Reporter:	Maciej Józefczyk <mjozefcz>
Component:	python-networking-ovn	Assignee:	Maciej Józefczyk <mjozefcz>
Status:	CLOSED ERRATA	QA Contact:	Roman Safronov <rsafrono>
Severity:	high	Docs Contact:
Priority:	high
Version:	16.0 (Train)	CC:	apevec, jlibosva, lhh, majopela, scohen
Target Milestone:	z2	Keywords:	Triaged
Target Release:	16.0 (Train on RHEL 8.1)	Flags:	mjozefcz: needinfo-
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	python-networking-ovn-7.1.1-0.20200225141602.ffa09ff.el8ost	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-05-14 12:08:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Maciej Józefczyk 2020-02-17 15:00:39 UTC

Description of problem:
While creating a Network or Port the qos rows are not created.

The qos ovn extension plugin is loaded:
2020-02-17 14:38:58.171 29 INFO networking_ovn.ml2.qos_driver [-] Starting OVNQosDriver

()[neutron@controller-0 /]$ grep -Ri qos /etc/neutron
/etc/neutron/neutron.conf:service_plugins=qos,ovn-router,trunk,segments
/etc/neutron/neutron.conf:#rabbit_qos_prefetch_count = 0
/etc/neutron/plugins/ml2/ml2_conf.ini:extension_drivers=qos,port_security,dns
/etc/neutron/plugin.ini:extension_drivers=qos,port_security,dns
()[neutron@controller-0 /]$ 



Version-Release number of selected component (if applicable):
RHOS_TRUNK-16.0-RHEL-8-20200213.n.1


Steps to Reproduce:
1. create neutron network + policy
2. create port
3. validate that the qos row is not created

Actual results:
qos row not created

Expected results:
qos row referenced lsp should be created

Additional info:
The same should be while qos specified on network but not on port.

Comment 11 Roman Safronov 2020-04-19 10:45:15 UTC

Verified on puddle 16.0-RHEL-8/RHOS_TRUNK-16.0-RHEL-8-20200406.n.1 with python3-networking-ovn-7.1.1-0.20200403214619.4114bc5.el8ost.noarch

Verified that when network has a qos policy and a port is created attached to the network a corresponding qos entry is created in NBDB
i.e. on undercloud:
openstack subnet create subnet_A --network internal_A --subnet-range 192.168.1.0/24
openstack network set --qos-policy bw-limiter internal_A
openstack port create --network internal_A portA1
on controller node
ovn-nbctl qos-list <ID of LogicalSwitch of internal_A network>
Result: QoS entry exist

Verified that when network does not have a qos policy and a port with a qos policy is created attached to the network a corresponding qos entry is created in NBDB
i.e. on undercloud:
openstack network create internal_B
openstack subnet create subnet_B --network internal_B --subnet-range 192.168.2.0/24
openstack port create --network internal_B   --qos-policy bw-limiter     portB1
on controller node
ovn-nbctl qos-list <ID of LogicalSwitch of internal_B network>
Result: QoS entry exist

However, in case port is updated by setting s qos policy a corresponding qos entry is not created, I opened a separate bug on this: https://bugzilla.redhat.com/show_bug.cgi?id=1825599
Also, when ports are deleted NBDB still contains the qos entries: https://bugzilla.redhat.com/show_bug.cgi?id=1824799

Comment 15 errata-xmlrpc 2020-05-14 12:08:10 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/RHBA-2020:2164