ASG/RG can't do rolling updates of provider resources

Bug #1767514 reported by Zane Bitter
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
New
Medium
Unassigned

Bug Description

When passing a files dict to a nested stack, we are no able to specify one set of files for one group of resources and a different set for another group. As a consequence of that, when the scaled unit of a ResourceGroup or AutoScalingGroup is a provider template (i.e. the user specifies a template as the type of a scaled unit), all of the members will see the updated files at the same time, even during a rolling update that is supposed to update only a portion of the members.

One consequence of this is bug 1765454: if the template name changes then the old template may be missing from the files dict. But there are equally bad consequences when the template name does *not* change.

When only the child template is changed, all of the resources will be updated on the first update and there will be no rolling update even if the user requested one.

When both the child template and the resource definition are changed, for example to add a new parameter, some resources will get an unholy mix of the old resource definition with the new template for a while. If e.g. a new parameter was added with a non-default value, this will actually cause errors and prevent the rolling update from completing successfully.

The solution could be to define pseudo-types for the old and new templates (InstanceGroup and it's children already use OS::Heat::ScaledResource, so something like OS::Heat::ScaledResource::<version> would make sense) and pass a mapping in the child environment to the old and new versions of the file.

Revision history for this message
Zane Bitter (zaneb) wrote :

It occurs to me that we could potentially encounter the same issue at the next layer down with any provider resources contained in the scaled unit. I'm not sure what the answer to that is. Duplicating all of the files and rewriting the child templates/environments to map all of the right versions seems like it would get out of hand quite quickly.

Maybe we have to add a parameter to the stack-update RPC call to limit which resources can be updated? (As long as we only use it internally - i.e. for stuff that we know has no dependencies - it might not be too hard to exclude some resources from the graph.)

Rico Lin (rico-lin)
Changed in heat:
milestone: none → no-priority-tag-bugs
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.