Sticky parameters

Problem:
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
https://blueprints.launchpad.net/heat/+spec/retry-failed-update

Dependency for handling failed stack update:
Update Failure Recovery
       https://blueprints.launchpad.net/heat/+spec/update-failure-recovery