Comment 9 for bug 1521944

I think I am seeing a similar issue.
The key points are that a failed stack-update where the "environment" was changed will lead to a un-recoverable scenario and an un-deletable stack. It becomes un-deletable because the resource-registry entry no longer exists. I believe that is the main difference between my env and the original stacks provided for this bug.

(I will attach my sample files as well.)

Step 1) heat stack-create -f Step1.yaml -e Step1.env STAK
-This creates a stack with a network and a subnet. The subnet is part of the custom resource.

Step 2) neutron port-create --name JUNK <uuid of network>
-This implicitly creates a port on the subnet, which will prevent us from being able to delete the subnet

Step 3) heat stack-update -f Step2.yaml STAK
- The update tries to delete the subnet (Env:SubNet custom resource) because Step2.yaml no longer references it. The update will fail because of Step 2, which leads to the real problem.

Step 4) neutron port-delete <UUID of port created in Step 2>
- We should now be able to delete the subnet, and our stack

Step 5) heat stack-delete STAK
ERROR: The Resource Type (ENV::SubNet) could not be found.
- I have not been able to determine a way to recover or remove this stack without going into the DB.