Bug 1572706 - os-collect-config should retry signaling success of a resource if it receives a 500 error message from heat
Summary: os-collect-config should retry signaling success of a resource if it receives...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-heat-templates
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: async
: 10.0 (Newton)
Assignee: Alex Schultz
QA Contact: Sasha Smolyak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-27 16:06 UTC by Andreas Karis
Modified: 2019-10-16 09:40 UTC (History)
9 users (show)

Fixed In Version: openstack-heat-templates-0-0.16.1e6015dgit.el7ost
Doc Type: Bug Fix
Doc Text:
Previously, the heat configuration notification process would not retry if heat was temporarily unavailable during a stack action. The heat task would hang indefinitely waiting for a response and the action would timeout. This issue has been resolved by adding a notification process retry when the Heat API endpoint returns a 503 or 504.
Clone Of:
Environment:
Last Closed: 2019-10-16 09:40:17 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:3119 0 None None None 2019-10-16 09:40:19 UTC

Description Andreas Karis 2018-04-27 16:06:08 UTC
Description of problem:
os-collect-config should retry signaling success of a resource if it receives a 500 error message from heat

In a customer environment, we can observe the following behavior:

* Director services are making the undercloud churn a lot
* communication between heat and keystone breaks temporarily due to load on undercloud
* heat returns 500 code to the compute's os-collect-config when the latter signals the success of resource ComputeSshKnownHostsDeployment
* os-collect-config never tries to signal the success of that resource again

Expected results:
os-collect-config should retry

Comment 5 Alex Schultz 2019-06-21 21:06:56 UTC
Turns out I fixed this back in 2017.  https://review.opendev.org/#/c/519417/ So it's in openstack-heat-agents >= 1.5.1 which shipped with OSP13. I'll see about backporting this to OSP10.

Comment 8 errata-xmlrpc 2019-10-16 09:40:17 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/RHEA-2019:3119


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