On 08/01/15 05:39, Anant Patil wrote:
1. The stack was failing when there were single disjoint resources or just one resource in template. The graph did not include this resource due to a minor bug in dependency_names(). I have added a test case and fix here: https://github.com/anantpatil/heat-convergence-prototype/commit/b58abd77cf596475ecf3f19ed38adf8ad3bb6b3b
Thanks, sorry about that! I will push a patch to fix it up.
2. The resource graph is created with keys in both forward order traversal and reverse order traversal and the update will finish the forward order and attempt the reverse order. If this is the case, then the update-replaced resources will be deleted before the update is complete and if the update fails, the old resource is not available for roll-back; a new resource has to be created then. I have added a test case at the above mentioned location. In our PoC, the updates (concurrent updates) won't remove a update-replaced resource until all the resources are updated, and resource clean-up phase is started.
Hmmm, this is a really interesting question actually. That's certainly not how Heat works at the moment; we've always assumed that rollback is "best-effort" at recovering the exact resources you had before. It would be great to have users weigh in on how they expect this to behave. I'm curious now what CloudFormation does.
I'm reluctant to change it though because I'm pretty sure this is definitely *not* how you would want e.g. a rolling update of an autoscaling group to happen.
It is unacceptable to remove the old resource to be rolled-back to since it may have changes which the user doesn't want to loose;
If they didn't want to lose it they shouldn't have tried an update that would replace it. If an update causes a replacement or an interruption to service then I consider the same fair game for the rollback - the user has already given us permission for that kind of change. (Whether the user's consent was informed is a separate question, addressed by Ryan's update-preview work.)
and that's why probably they use the roll-back flag.
I don't think there's any basis for saying that. People use the rollback flag because they want the stack left in a consistent state even if an error occurs.
cheers, Zane. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
