hieradata change doesn't reapply manifest
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Heat Templates |
In Progress
|
High
|
Steven Hardy | ||
tripleo |
Fix Released
|
High
|
Steven Hardy |
Bug Description
Due to the way we've separated the creation of hieradata and subsequent deployment config passes where puppet manifests configure the node using the data, an invisible (to heat) dependency exists between the hieradata SoftwareConfig and all puppet-applying deployment resources.
This manifests itself as a failure to apply config changes, for example setting "Debug" to True then doing a stack-update on the overcloud fails, in that the puppet hooks aren't re-triggered to apply the now-modified hieradata
There are a few possible fixes - probably the most correct one is to explicitly express the dependency between the two deployments e.g by exposing an output in controller-
Changed in tripleo: | |
status: | New → Triaged |
Changed in tripleo: | |
importance: | Undecided → High |
Changed in tripleo: | |
assignee: | nobody → Steve Baker (steve-stevebaker) |
Changed in heat-templates: | |
assignee: | nobody → Steven Hardy (shardy) |
status: | New → In Progress |
importance: | Undecided → High |
Changed in tripleo: | |
status: | In Progress → Fix Committed |
Changed in tripleo: | |
status: | Fix Committed → Fix Released |
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.