Comment 7 for bug 1442121

Regardless of the proper way to associate ports with subnets, people will get it wrong, leaving broken stacks in their wake when stack-delete fails due this kind of race condition (current example in our cloud: a stack gets stuck in state DELETE_IN_PROGRESS, `heat resource-list` on the stack blows up with a NetworkNotFoundClient exception and `heat stack-abandon` fails as well).

As far as I can see, adding exception handling in places like https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/neutron/floatingip.py#L169 should go a long way towards ameliorating the problem: if a Neutron resource (such as a network) no longer exists, it needn't be added as a dependency either. Is my reasoning correct there, or are there some side effects I might be overlooking?

The current state of affairs leaves something to be desired, at any rate: one cannot even attempt to clean up manually if somebody instantiates a broken template, because this lack of exception handling breaks resource-list, effectively blinding the operator (short of plucking resource IDs from Heat's database, that is).