Bug 2028505

Summary: Overcloud update fails on the first controller
Product: Red Hat OpenStack Reporter: Eric Nothen <enothen>
Component: openstack-tripleo-heat-templatesAssignee: Damien Ciabrini <dciabrin>
Status: CLOSED DUPLICATE QA Contact: pkomarov
Severity: high Docs Contact:
Priority: high    
Version: 16.1 (Train)CC: bshephar, jjoyce, jschluet, lmiccini, mbayer, mburns, slinaber, tvignaud
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-29 12:08:17 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 Eric Nothen 2021-12-02 14:24:11 UTC
Description of problem:
An overcloud update fails on the first controller at the task "Wait for containers to start for step 2 using paunch". Times out after 650 retries (rougly 30 minutes).
When the overcloud update is retried without any change done on the controller, it completes without the error. Afterwards, the overcloud is fully available. 


Version-Release number of selected component (if applicable):
16.1.4 to 16.1.6

How reproducible:
Customer ran into this issue on the first 2 clusters they updated. I have not been able to reproduce yet.

Steps to Reproduce:
1.
2.
3.

Actual results:
Overcloud update fails on the first controller that is updated.


Expected results:
Overcloud update completes on the first try without error.


Additional info:
Attaching case with sosreport from the controller and output of ansible job.

Comment 7 Eric Nothen 2021-12-10 08:51:15 UTC
Now that BZ#2015325 is resolved, I'll ask my customer if it's possible to test the update from 16.1.4 to 16.1.7, and if it works well we can assume this bug is a duplicate of the other and close it.

Comment 9 Eric Nothen 2022-02-09 18:08:21 UTC
Customer confirmed on the attached case that the workaround for this issue is the same detailed on BZ#2015325 (removing mariadb-server in advance), so this BZ can be closed as duplicate.

Comment 10 Luca Miccini 2022-06-29 12:08:17 UTC

*** This bug has been marked as a duplicate of bug 2015325 ***