I had a chat with Dan and the options could be summarised as:
1) Similar to UpdateIdentifier, add an ApplyConfigIdentifier so that puppet-apply gets run when a unique value is set
2) digest all the hieradata deployments in the heat templates and feed that into the PostDeployment resource input_values so puppet-apply gets run whenever there is a hieradata change
3) replace the heat-config 55-heat-config with a dedicated orc script which builds the hieradata, digests it all, and decides whether to run puppet-apply.
Which one to do depends on what the actual use-cases are for deployers/operators choosing when to run puppet-apply. They might *want* to do a series of stack-updates which change hieradata, then do a puppet-apply update at the end. Or they might *never* want to do a manual update, and just want it to happen automatically always.
If it is the former, I'd recommend 1), otherwise I'd recommend 3).
2) might be quicker than 3) to implement, but it may result in harder to maintain templates.
I had a chat with Dan and the options could be summarised as:
1) Similar to UpdateIdentifier, add an ApplyConfigIden tifier so that puppet-apply gets run when a unique value is set
2) digest all the hieradata deployments in the heat templates and feed that into the PostDeployment resource input_values so puppet-apply gets run whenever there is a hieradata change
3) replace the heat-config 55-heat-config with a dedicated orc script which builds the hieradata, digests it all, and decides whether to run puppet-apply.
Which one to do depends on what the actual use-cases are for deployers/operators choosing when to run puppet-apply. They might *want* to do a series of stack-updates which change hieradata, then do a puppet-apply update at the end. Or they might *never* want to do a manual update, and just want it to happen automatically always.
If it is the former, I'd recommend 1), otherwise I'd recommend 3).
2) might be quicker than 3) to implement, but it may result in harder to maintain templates.