OS::Heat::SoftwareComponent now allows non-lifecycle configs to be specified. This feature will make it possible to trigger these configs and monitor their progress and results.
OS::Heat::SoftwareComponent can specify configs to execute for stack lifecycle actions (CREATE, DELETE etc) but it can also specify any non-lifecycle actions (eg BACKUP, FOO, BAR). However there is currently no obvious way to trigger these non-lifecycle actions. Once this feature is complete it should be possible to use the heat CLI tool to do the following:
Hypothetically it is already possible to trigger a single action config in a SoftwareComponent by interacting directly with the REST API, however there is no way to receive the results of this trigger.
Consider a SoftwareComponent which defines a config that runs on the action BACKUP. Once stack creation is complete the following would have happened:
Now to trigger BACKUP on a given server in the stack (optionally with some extra input values set), REST API calls can be made to:
The above will all be performed by a single heat deployment-create command where the user can specify all the values required to create a deployment, including the config, server, name, action, overridden input values, etc.
Changes will be required to move some OS::Heat::SoftwareDeployment into the deployment create call itself.
This blueprint will also depend on blueprint software-config-swift-signal since there will need to be a signal store which is not coupled with any stack or resources.
python-heatclient will need to be modified so that all software-config and deployment operations can be done from the command line. New convenience commands will also be added to trigger and monitor a single action in a component.
This could also be an appropriate umbrella blueprint to switch to using RPC instead of full REST calls for when config and deployment resources call config and deployment APIs.
Currently python-heatclient lacks any cli commands to manage software configs and deployments. A prerequisite for this change is cli support for interacting with the existing config and deployment REST API, including
Once these have been implemented, new convenience commands will also be added to trigger and monitor a single action in a component.
In heat, the following changes would be required:
Not a hard dependency, but this would benefit from blueprint software-config-progress being implemented to provide the user with feedback that their config trigger has started.
If it is deemed inappropriate to modify EngineService.resource_signal then some alternative external polling based signaling would be required, as provided by blueprint software-config-swift-signal or blueprint software-config-zaqar.