[openstack-dev] [Heat] Convergence proof-of-concept showdown
zbitter at redhat.com
Fri Jan 9 22:57:21 UTC 2015
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:
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
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
More information about the OpenStack-dev