path: root/extraconfig/post_deploy
AgeCommit message (Collapse)AuthorFilesLines
2016-03-23Add ExtraConfig example that always runs on updateSteven Hardy1-0/+39
Some user feedback indicates we need better examples showing how we can run an extraconfig template, e.g on post-deploy so that it runs every update, regardless of if a change to the config has occurred. We can leverage DeployIdentifier for this, just like with the puppet deployments. This can be tested with an example like this: resource_registry: OS::TripleO::NodeExtraConfigPost: tripleo-heat-templates/extraconfig/post_deploy/example_run_on_update.yaml Change-Id: I45d8f8093ab45c03238ec56651c437128661cb95
2015-12-10Set the name property for all deployment resourcesSteve Baker1-0/+1
There are two reasons the name property should always be set for deployment resources: - The name often shows up in logs, files and API calls, the default derived name is long and unhelpful - Sorting by name determines the merge order of os-apply-config, and the execution order of puppet/shell scripts (note this is different to resource dependency order) so leaving the default name results in an undetermined order which could lead to unpredictable deployment of configs This change simply sets the name to the resource name, but a future change should prepend each name with a run-parts style 2 digit prefix so that the order is explicitly stated. Documentation for extraconfig needs to clearly state what prefix is needed to override which merge/execution order. For existing overcloud stacks, heat currently replaces deployment resources when the name changes, so this change Depends-On: I95037191915ccd32b2efb72203b146897a4edbc9 Change-Id: Ic4bcd56aa65b981275c3d4214588bfc4de63b3b0
2015-10-01Move RHEL (un)registration to NodeExtraConfigSteven Hardy5-276/+0
Currently, we have a problem because the unregistration happens in the "post deploy" phase, which works fine when the top-level stack is being deleted, but not when the ResourceGroup of servers is being scaled down, because then the normal "post deploy" update ordering is respected and we try to unregister after the corresponding server has been deleted. So, instead, register/unregister each node inside the unit of scale, e.g the role template being scaled down, which is possible via the new NodesExtraConfig interface, which means unregistration will take place at the right time both on stack delete and on scale-down. Change-Id: I8f117a49fd128f268659525dd03ad46ba3daa1bc
2015-07-09RHEL registration shouldn't use attach with activation keyJohn Trowbridge1-1/+1
In the case of using portal registration with an activation key, the RHEL registration script is still executing a `subscription-manager attach` command. This should not happen if an activation key is provided. This is because an activation key already provides the subscriptions to attach. Change-Id: I2907bede28a9b7bef71cedeea69c876eb4949df0
2015-07-06Wire in Controller pre-deployment extraconfigSteven Hardy1-0/+2
The recently added cinder-netapp extraconfig contains some additional hieradata which needs to be applied during the initial pre-deployment phase, e.g in controller-puppet.yaml (before the manifests are applied) so wire in a new OS::TripleO::ControllerExtraConfigPre provider resource which allows passing in a nested stack (empty by default) which contains any required "pre deployment" extraconfig, such as applying this hieradata. Some changes were required to the cinder-netapp extraconfig and environment such that now the hieradata is actually applied, and the parameter_defaults specified will be correctly mapped into the StructuredDeployment. Change-Id: I8838a71db9447466cc84283b0b257bdb70353ffd
2015-06-18Use SoftwareDeployments for consistency in extraconfigSteven Hardy2-3/+3
Currently we've got a mix of SoftwareConfig resource with StructuredDeployments resources - while this will work it's inconsistent and normally using the corresponding SoftwareDeployments resouce is encourgaged instead. Change-Id: I308d62d4ff491c073e3e8650fd4c2c65bf96d14a
2015-05-07post-deploy hook for rhel registrationSteven Hardy5-0/+276
Adds a potential usage of the post-deploy hooks to register a server with RHN or a satellite. Note this requires some additional parameters, which can be specified in environment_rhel_reg.yaml, and this must be passed into the call to heat via another -e parameter. An alternative may be to have a global extraconfig_env.yaml at the top level, which the scripts always pass, or to use the global environment (/etc/heat/environment.d/default.yaml) on the seed. Co-Authored-By: James Slagle <jslagle@redhat.com> Change-Id: Ia6fd270122cbc2e51beb672654e5e1ebd3bd2966
2015-04-24Add hooks for extra post-deployment configSteven Hardy2-0/+32
Adds optional hooks which can run operator defined additional config on nodes after the application deployment has completed. Change-Id: I3f99e648efad82ce2cd51e2d5168c716f0cee8fe