Thanks to various bug fixes, the stack-cancel-update command now works under convergence. However, it does not recursively cancel nested stacks. The nested stacks will eventually be updated as part of the rollback of the parent stack, but in the meantime they will continue updating resources that they'll eventually just have to roll back, and we won't be able to start said rollback at least until the current update has completed or failed. It would be more optimal if we could recursively stop the traversals on nested stacks as soon as we receive the stack-cancel-update command, so that we wouldn't do any unnecessary/unwanted work prior to the rollback starting.
We now do basically that in the legacy path: where most resources have a grace period of 4 minutes to complete or fail before we cancel them (note: in convergence the grace period effectively extends until the stack timeout), resources that provide a handle_<action>_cancel() method are cancelled immediately, causing that method to be called. (Although in practice nested stacks are currently the only resources to make use of the mechanism, it is generic enough that other resource types that can be safely cancelled can take advantage.)
An option I discussed with Anant in http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2016-08-29.log.html#t2016-08-29T19:53:48 would be to piggy-back on the same mechanism for convergence. We could send a message to all resources in a stack to hard-cancel (i.e. kill the thread) *only* if the resource provides a handle_<action>_cancel() method. That way the initial soft-cancel (i.e. stopping the traversal) would propagate immediately down through all the nested stacks.
Fix proposed to branch: master
Review: https:/