Delete vnf should delete its corresponding stack (even in failure)

[Santosh]

When we have a situation where maximum vm limit is reached, and we create vnf say vnf_new, in background stack creation with id say id1 fails(because of max vm limit is reached).
Now vnf_new status is stuck in pending_create.At this point when we delete vnf_new, stack id1 stale entry is still there not getting deleted. This operation will create stale entries.

[Sridhar Ramaswamy (srics-r)]

Could be the same root cause as in for https://bugs.launchpad.net/tacker/+bug/1497035

[Sridhar Ramaswamy (srics-r)]

Thinking further this bug reports beyond what is reported in #1497035 (mentioned above).

1) Here is the call sequence... vnf-create --> stack_create. When the later fails , for whatever reason - be it nova issue, neutron port binding issue (as seen in #1497035) or capacity issue (as seen by this bug).. tacker should move VNF status from PENDING_CREATE to ERROR state - which appropriate error message

2) If for some reason VNF create is stuck in PENDING_CREATE (say heat is taking a long time), a VNF delete should cleaning delete the backend resources (like the heat-stack).

[vishwanath jayaraman (vishwanathj)]

FYI: This is similar to the bug https://bugs.launchpad.net/tacker/+bug/1475798

[vishwanath jayaraman (vishwanathj)]

The fix for https://bugs.launchpad.net/tacker/+bug/1499067 will fix this issue as well.
The root cause for this issue and 1499067 is that the wrong exception was being thrown at https://github.com/stackforge/tacker/blob/master/tacker/vm/drivers/heat/heat.py#L355.
The DeviceCreateWaitFailed exception had to be thrown instead of the RuntimeError exception.
The https://github.com/stackforge/tacker/blob/master/tacker/vm/plugin.py#L261-L263 ensures that a stack failure is properly handled when DeviceCreateWaitFailed exception is thrown. It also ensures that the status is set to ERROR as part of https://github.com/stackforge/tacker/blob/master/tacker/vm/plugin.py#L272-L276