Bug 1829293 - SRIOV OVN metadata namespaces not cleaned up after ports are unbounded
Summary: SRIOV OVN metadata namespaces not cleaned up after ports are unbounded
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 16.1 (Train)
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: beta
: 16.1 (Train on RHEL 8.2)
Assignee: Jakub Libosvar
QA Contact: Eduardo Olivares
URL:
Whiteboard:
Depends On:
Blocks: 1666684
TreeView+ depends on / blocked
 
Reported: 2020-04-29 11:01 UTC by Eduardo Olivares
Modified: 2020-07-29 07:52 UTC (History)
5 users (show)

Fixed In Version: python-networking-ovn-7.1.1-0.20200507153427.fd1c0c3.el8ost
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-29 07:52:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1875865 0 None None None 2020-04-29 11:13:49 UTC
OpenStack gerrit 724287 0 None MERGED [ovn] Add PortBinding delete event for external ports 2020-07-22 13:43:46 UTC
OpenStack gerrit 725231 0 None MERGED [ovn] Add PortBinding delete event for external ports 2020-07-22 13:43:46 UTC
Red Hat Product Errata RHBA-2020:3148 0 None None None 2020-07-29 07:52:43 UTC

Description Eduardo Olivares 2020-04-29 11:01:21 UTC
Description of problem:
See 'Steps to Reproduce' below.

According to jlibosva:
The external port is deleted from the port_binding table instead of chassis removed and then deleted so the PortBindingUpdate event is never generated.

The metadata agent reacts on Port Binding Update event only. That means when there is a VM and we delete it, it first calls port update to remove the chassis from the port binding, so the port binding is chassis=[] before the PB gets deleted.
In SRIOV scenario we don't do that and we delete a port that is bound.

We need a special event for the sriov deletion case.


Version-Release number of selected component (if applicable):
RHOS-16.1-RHEL-8-20200424.n.0
python3-networking-ovn-7.1.1-0.20200422213423.1d7e326.el8ost.noarch


How reproducible:
100%

Steps to Reproduce:
1. create an SRIOV port on either a tenant or a prov network + create a VM attached to that port - check ovn metadata namespace has been created on a GW node
2. remove that VM - the ovn metadata namespace is not removed from that GW node
3. even after removing the port, the namespace is not removed

Actual results:
OVN metadata namespaces clean up mechanism not working with SRIOV ports

Expected results:
Namespaces should be removed after port is removed

Additional info:

Comment 5 Eduardo Olivares 2020-07-08 16:43:33 UTC
Verified on:
RHOS-16.1-RHEL-8-20200701.n.0
python3-networking-ovn-7.2.1-0.20200611111150.18fabca.el8ost.noarch

Verification Steps:
1. create an SRIOV port on either a tenant or a prov network + create a VM attached to that port - check ovn metadata namespace has been created on a GW node

(undercluod) # openstack port create --vnic-type direct --network nova --binding-profile trusted=true sriov-port-prov-0 && openstack server create --image tempest_image --flavor rhel_flavor_1ram_1vpu_10disk --port sriov-port-prov-0 vm-sriov-prov-0

(controller-0) # ip netns
ovnmeta-fc5a58e8-0e6a-4f09-a6dd-3968c26d6ee3 (id: 0)


2. remove that VM - the ovn metadata namespace is not removed from that GW node
(undercloud) # openstack server delete vm-sriov-prov-0

(controller-0) # ip netns
ovnmeta-fc5a58e8-0e6a-4f09-a6dd-3968c26d6ee3 (id: 0)


3. after removing the port, the namespace is removed
(undercloud) # openstack port delete sriov-port-prov-0

(controller-0) # ip netns
(empty, no namespace shown)

Comment 7 errata-xmlrpc 2020-07-29 07:52:15 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:3148


Note You need to log in before you can comment on or make changes to this bug.