I can't replicate this using a simple template and the heat-templates software-config hook and current heat master - it appears to do the right thing when scaling up and down.
I think I see what the issue might be. Currently templates have a pattern like this:
and os-refresh-config/post-configure.d/99-refresh-completed will signal the *one* URL set by completion-signal. What
99-refresh-completed should be doing is iterating all deployments and signalling every deploy_signal_id it finds. This will allow multiple deployment resources to be signalled instead of just one random one.
Once 99-refresh-completed is modified to do this, the templates no longer need to specify completion-signal: {get_input: deploy_signal_id} (although 99-refresh-completed could continue to signal an optional completion-signal)
I can't replicate this using a simple template and the heat-templates software-config hook and current heat master - it appears to do the right thing when scaling up and down.
I think I see what the issue might be. Currently templates have a pattern like this:
allNodesConfig: :StructuredConf ig
completion- signal: {get_input: deploy_signal_id}
type: OS::Heat:
properties:
config:
and os-refresh- config/ post-configure. d/99-refresh- completed will signal the *one* URL set by completion-signal. What completed should be doing is iterating all deployments and signalling every deploy_signal_id it finds. This will allow multiple deployment resources to be signalled instead of just one random one.
99-refresh-
Once 99-refresh- completed is modified to do this, the templates no longer need to specify completion-signal: {get_input: deploy_signal_id} (although 99-refresh- completed could continue to signal an optional completion-signal)