Bug 1427969
| Summary: | Heat stack delete fails due to clock skew | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Jeremy <jmelvin> | |
| Component: | openstack-heat | Assignee: | Zane Bitter <zbitter> | |
| Status: | CLOSED ERRATA | QA Contact: | Amit Ugol <augol> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | low | |||
| Version: | 10.0 (Newton) | CC: | mburns, rhel-osp-director-maint, sbaker, shardy, srevivo, zbitter | |
| Target Milestone: | z4 | Keywords: | Triaged, ZStream | |
| Target Release: | 10.0 (Newton) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | openstack-heat-7.0.3-2.el7ost | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1459981 (view as bug list) | Environment: | ||
| Last Closed: | 2017-09-06 17:13:53 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1459981 | |||
|
Description
Jeremy
2017-03-01 15:40:05 UTC
This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release. One main issue here seems to be that once the nested stack goes into a DELETE_FAILED state, subsequent attempts to delete the parent resource can poll the nested stack state before it goes back to DELETE_IN_PROGRESS, see the old error, and immediately mark the parent resource failed again. There is code in place to ensure this doesn't happen on UPDATE, but it is not invoked on DELETE. It's not clear to me why the operation is timing out in the first place, though. I take it the stack is not being created with a really short timeout value? the customer isn't setting short timeout. he is just using : openstack stack create timeout-test3 -t autoscaling_web_demo.yaml Hello, Any update on this? THanks, Jeremy Aha, I've tracked down the cause. There's a skew between the clocks of the different nodes of around 5s or so (controller_0 is the slow one), and a bug in Heat that causes timeouts when the difference between the start time and the current time is negative. I'll fix the bug upstream. In the meantime, an easy workaround would be to sync the clocks. 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-2017:2655 |