Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1632295

Summary:	Ignore spurious nested stack locks in convergence
Product:	Red Hat OpenStack	Reporter:	Zane Bitter <zbitter>
Component:	openstack-heat	Assignee:	Zane Bitter <zbitter>
Status:	CLOSED WONTFIX	QA Contact:	Ronnie Rasouli <rrasouli>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	12.0 (Pike)	CC:	cylopez, mburns, pamadio, ramishra, rrasouli, sbaker, shardy, srevivo, therve
Target Milestone:	---	Keywords:	Triaged, ZStream
Target Release:	12.0 (Pike)
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: When convergence is enabled for a stack, the "stack check" operation uses a different type of locking (stack-level instead of resource-level) from regular operations such as "stack update" or "stack delete". However, when processing nested stacks they are not considered complete until any stack-level lock is released. Consequence: Any stale locks left behind in a nested stack by a stack check will cause the parent stack to time out when updating or deleting the nested stack. Fix: Ignore the stack-level locks when checking the completion of any nested stack operation (like update or delete in convergence stacks) that uses only resource-level locks. Result: Any stray locks left behind in the database will not prevent further operations on the nested stack.	Story Points:	---
Clone Of:	1626367
Clones:	1632313 (view as bug list)		Environment:
Last Closed:	2018-12-14 06:15:42 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:	1626367
Bug Blocks:	1632313

Description Zane Bitter 2018-09-24 15:30:00 UTC

+++ This bug was initially created as a clone of Bug #1626367 +++

This is a bug to request a backport of this change on RHOSP11:

https://review.openstack.org/#/c/598354/

Several operations (e.g. stack check) are yet to be converted to convergence-style workflows, and still create locks. While we try to always remove dead locks, it's possible that if one of these gets left behind we won't notice, since convergence doesn't actually use stack locks for most regular operations. When doing _check_status_complete() on a nested stack resource, we wait for the operation to release the nested stack's lock before reporting the resource completed, to ensure that for legacy operations the nested stack is ready to perform another action on as soon as the resource is complete. For convergence stacks this is an unnecessary DB call, and it can lead to resources never completing if a stray lock happens to be left in the database. Only check the nested stack's stack lock for operations where we are not taking a resource lock. This corresponds exactly to legacy-style operations.