Heat (icehouse) is rarely able to successfully delete stacks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
New
|
Undecided
|
Unassigned |
Bug Description
I have been creating and deleting stacks frequently over the past few days, and I am become unnecessarily familar with the "heat stack-abandon" command. It appears as if Heat has an ordering problem when attempting to delete stacks that contain floating ip addresses. I am deploying using this template:
https:/
Typically, when I try to delete the stack, it ends up in the DELETE_FAILED state and logs the following error:
2014-08-30 20:52:37.683 19534 TRACE heat.engine.
If I manually delete the server to which the floating ip is attached, the delete then fails because Heat is unable to delete the Docker container resources I have defined (because I have deleted the server that was hosting the resources):
2014-08-30 22:50:48.002 19534 TRACE heat.engine.
While all of these depdendencies make great sense when *creating* a stack, I'm beginning to feel that Heat is a little too strict when *deleting* a stack. There ought to be something between "heat stack-delete" and "heat stack-abandon" that will attempt to delete all stack resources and that will ignore errors. Something like "heat stack-delete --force". While "stack-abandon" is able to clear the error, it requires one to manually delete the entire resource stack, which can be time consuming and problematic if you forget to delete something and you unexpectedly run up against your Neutron security group quota.
Or perhaps a "resource-abandon" command, if not a "delete --force".
Lars, this looks like a duplicate of bug #1299259 which has a suggested workaround https:/ /bugs.launchpad .net/heat/ +bug/1299259/ comments/ 4
Can you try adding this depends_on to your template: server_ floating: :FloatingIP"
docker_
type: "OS::Neutron:
depends_on: extrouter_inside
properties:
...
This issue is that neutron's domain model doesn't map very well with their API, so there are implicit resource dependencies which show up as race conditions on stack create or stack delete. In this particular case the race is only triggered on stack delete.
We already have a bunch of workarounds for these neutron issues, but bug #1299259 hasn't been fixed yet (it will be for Juno)
Let us know if the workaround works for you, and mark this as a duplicate if so.