Sticky parameters

Registered by Ton Ngo

When a Heat template is deployed and an error occurs, the VM's are rolled back and deleted if rollback is enabled. Server logs can help to determine the problem, but often we need to log into the VM's being deployed to debug the scripts and environment. To pause the template deployment at the point of error, we can re-create the stack with rollback disabled and then inspect the partial stack. For instance, the resource-list and resource-show commands would display the state of the resources. After troubleshooting and potentially correcting the error, the stack will have to be re-created from scratch.

This blueprint proposes allowing the stack deployment to be continued after the environment problem has been corrected, instead of forcing the stack to be re-created. This will help to speed up template development because the resources in good state do not need to be taken down and re-created. Avoiding repeating the full cycle should be particularly helpful for large template. This also provides the necessary low level support for advanced development tool to be built.

This blueprint builds upon the blueprint update-failure-recovery, which would make consistent the state of a failed stack update, and the blueprint retry-failed-update, which allows update to a failed stack. The consistent state allows any failed stack to be continued simply by running stack-update using the same template, parameters and environment again. In the process, the engine will attempt to recreate the failed resources since they will not exist in the current stack.

However, requiring the users to re-enter exactly the same stack input is awkward and can introduce inadvertent error. To help make troubleshooting more intuitive and convenient, the stack-update command will be changed to allow the format:
   heat stack-update my_failed_stack --existing
where the previous template, parameters, registry will be re-used.

To manage parameters more conveniently in stack-update, a new PATCH API is added for stack-update to allow reuse and patching. For the heat client, a new --existing option will perform the same operation.

For parameters, the new set of key:value will be patched over the set of parameters of the current stack. In other words, if a parameter was set previously, the new value will replace it. If a parameter is omitted in stack-update, the value set previously will be reused. If a new parameter is added to the template, the new key:value will be added to the previous set of parameters.

To allow choosing the default value in the template, a new option is added:
   heat stack-update my_failed_stack --existing --clear-parameters "param1;param2"
This removes the value previously set for a parameter and the default value in the template is used instead.

If the template does not specify a default value, the command returns with an error.
If the same parameter is specified in --parameters and --clear-parameters, then --parameters takes precedence.

The combined parameters will be validated normally against the template. Together, the two options above will allow the parameters to be modified arbitrarily without re-specifying the full set.

Similar support for registry and template will be added.

Related blueprint:
Use stack-update to attempt recovery of failed create or update

Dependency for handling failed stack update:
Update Failure Recovery

Blueprint information

Steve Baker
Ton Ngo
Series goal:
Accepted for juno
Milestone target:
milestone icon 2014.2
Started by
Ton Ngo
Completed by
Zane Bitter


Gerrit topic:,topic:bp/for,n,z

Addressed by:
    Add Heat engine support for troubleshooting failed stack

Gerrit topic:,topic:bp/troubleshooting-low-level-control,n,z

Addressed by:
    Add API suppport for troubleshooting failed stack

(stevebaker) At this point I see this as needing to be bumped to Juno

You should not set a milestone target unless the blueprint has been properly prioritized by the project drivers.

(zaneb) Ton and I discussed this on IRC yesterday. One issue with the current approach is that once update-failure-recovery is merged we won't actually have a copy of the last-used template any more. I'd also prefer to avoid having to add a whole new API. I suggested that a lot of the pain associated with retrying an update is not due to having to supply the template again but having to supply the *parameters* again. If we were to implement updates so that you only need to supply the subset of parameters that you want to change, and the other values are retained, then that would make _all_ updates better and largely obviate the need to introduce a new API.

Gerrit topic:,topic:bug/1224828,n,z

Addressed by:
    Pass flag to engine service to patch parameters

Addressed by:
    Pass list of parameters to engine service to reset

Addressed by:
    Add stack-update argument for reset parameters

Addressed by:
   Add stack-update argument for patching parameters


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.