Bug 1736854

Summary: Trunk subports sometimes not becoming ACTIVE and trunk:subport
Product: Red Hat OpenStack Reporter: Slawek Kaplonski <skaplons>
Component: openstack-neutronAssignee: Slawek Kaplonski <skaplons>
Status: CLOSED ERRATA QA Contact: Candido Campos <ccamposr>
Severity: high Docs Contact:
Priority: high    
Version: 13.0 (Queens)CC: amuller, asimonel, ccamposr, chrisw, eduen, ekuris, juriarte, mdulko, njohnston, scohen, shdunne, slinaber
Target Milestone: z11Keywords: Triaged, ZStream
Target Release: 13.0 (Queens)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-neutron-12.1.1-4.el7ost Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: 1733197 Environment:
Last Closed: 2020-03-10 11:26:10 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:
Bug Depends On: 1733197    
Bug Blocks: 1758669    

Description Slawek Kaplonski 2019-08-02 08:12:24 UTC 
+++ This bug was initially created as a clone of Bug #1733197 +++

Description of problem:
We're occasionally hitting a bug preventing Kuryr-Kubernetes from attaching ports to a trunk. The result of the operation on the API is 200, but ports never gets into ACTIVE and switches device_owner to trunk:subport. In our case Kuryr is creating those ports in bulks of 3, then tagging them one-by-one, then attaching to a trunk using random segmentation ID's.

Removing the subport from trunk and attaching it again resolves the issue.

In the logs of openvswitch-agent we see:

Remote error: StaleDataError UPDATE statement on table 'standardattributes' expected to update 1 row(s); 0 were matched.

Version-Release number of selected component (if applicable):
OSP14

How reproducible:
Occasionally. :(

Steps to Reproduce (I'm putting what Kuryr does):
1. Create 3 ports in bulk.
2. Tag them.
3. Add them to a trunk.

Actual results:
Sometimes port stays DOWN and still has what Kuryr put as device_owner instead of trunk:subport.

Expected results:
Port becomes ACTIVE and has trunk:subport as device_owner.

Additional info:
In the logs look for port 008a09d7-97a4-4aee-880c-c3dc5ad3d4f6, that's the affected one.

--- Additional comment from Michał Dulko on 2019-07-25 11:51 UTC ---
Comment 22 errata-xmlrpc 2020-03-10 11:26: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:0770