path: root/puppet/swift-storage-post.yaml
AgeCommit message (Collapse)AuthorFilesLines
2016-09-09Move role deployment steps into puppet/post.yamlSteven Hardy1-91/+0
To enable steps to be aligned between roles, we need to define dependencies between the steps, which is only possible if we move the steps out of distinct nested stacks so we can use depends_on to serialized the steps for all roles. Note that we may be able to further refactor later to remove the per-role -config.yaml nested stacks as well. Change-Id: Ia2ea559e8eeb64763908f75705e3728ee90b5744 Partially-Implements: blueprint custom-roles
2016-09-01Add default for DeployIdentifier in nested templatesSteven Hardy1-0/+1
Until we fix the bug where at validation time heat doesn't know if a parent passes a value into the nested template, this may be a workaround for validation failing where no default is found. Change-Id: I02b0764ac29700cd29584e356ac0cfebcda09a36 Closes-Bug: #1619352
2016-08-17Use modulepath for PuppetJiri Stransky1-0/+1
We only create the /etc/puppet/modules symlinks during image building, so as we update the openstack-puppet-modules RPM during the lifecycle of a deployment, the symlinks can get out of date and some modules aren't find. This patch adds modulepath for puppet deployments, getting rid of the need for our Puppet modules to be symlinked from /etc/puppet/modules. If there are some already symlinked, they will take precedence. Also modules installed from source to /opt/stack/puppet-modules will take precedence over packaged modules in /usr/share/openstack-puppet/modules. Change-Id: I626a596478be7c55500f9e3c7118ef64ff28aaae Closes-Bug: #1613211
2016-07-25Convert Swift ringbuilder to composable services formatSteven Hardy1-1/+0
This moves the ringbuilder puppet code to puppet-tripleo and migrates to the composable services format. Closes-Bug: #1601857 Change-Id: I0ea2230072d3ff61a4047ffff1f4187951370f67 Depends-On: I427f0b5ee93a0870d43419009178e0690ac66bd6
2016-07-04Replace NodeConfigIdentifiers with DeployIdentifierSteven Hardy1-7/+7
We added NodeConfigIdentifiers to trigger config to be re-applied on update, but then later added DeployIdentifier which forces config to *always* be applied on update, so we can simplify things by just referencing the DeployIdentifier directly. Change-Id: I79212def1936740825b714419dcb4952bc586a39
2016-07-01Pass RoleData into -post.yaml stacksDan Prince1-7/+6
This patch modifies the interface for the -post stacks so that we pass RoleData instead of just the StepConfig into each -post.yaml template. This will facilitate creating other types of -post.yaml scripts that require more data that just 'step_config'. Things like containers, etc. will require this. Change-Id: I2527fc0098192f092f5e9046033a04bc71be2cae
2016-05-31Configure ObjectStorage services via resource chainsSteven Hardy1-0/+5
Similar to the https://review.openstack.org/#/c/259568 which added support for the composable services StepConfig and ServiceConfigSettings parameters so that the Controller role supports composable services, this adds those interfaces for the ObjectStorage role. Note that at this time the ObjectStorage post config only supports steps 2, 3 and 4, not all those in services/README.rst Partially-Implements: blueprint composable-services-within-roles Change-Id: I22ffaa68a6ccd4be29d51674871268179bcddcbc
2016-05-31Fix inconsistency with ringbuilder/storage stepsSteven Hardy1-22/+26
Currently when deploying swift on the Controller nodes, we do the ringbuilder config during step3 and the swift-storage config during step 4, but this order is reversed on the ObjectStorage nodes. Also, we include the base swift class inconsistently during step2 on controller nodes, and via the overcloud-object manifest on ObjectStorage nodes. So fix this inconsistency as a precursor to conversion to composable services interfaces for the ObjectStorage role, we rework the post config so we apply the ObjectStorage config in steps 2, 3 and 4, which should hopefully get us much closer to the process used on the controller role, thus be easier to decompose in a compatible way. Partially-Implements: blueprint composable-services-within-roles Change-Id: Ic9d0ed8584a12d681a8f4d4742d39b96c15e531a
2016-05-18Add step to ObjectStorage RingBuilder deploymentSteven Hardy1-0/+5
https://review.openstack.org/#/c/236243 added a new conditional for the controller steps, but we don't pass any step for the ObjectStorage nodes, so the deployment fails. This passes a step that enables the ringbuilder again, although it does end up inconsistent with the deployment Step name. Change-Id: I506961f4a22dba9960d819d7376a39e7ccbcdece Closes-Bug: #1583225
2016-02-26Add support for DeployArtifactURLsDan Prince1-1/+12
Adds a new nested stack deployment which allows operators to opt-in to deploy tarball's and RPM packages by setting DeployArtifactURLs as a parameter_default in a Heat environment. The intent is to use this setting to allow t-h-t to transparently deploy things like tarballs of puppet modules via a Swift Temp URL. Change-Id: I1bad4a4a79cf297f5b6e439e0657269738b5f326 Implements: blueprint puppet-modules-deployment-via-swift
2015-12-10Set the name property for all deployment resourcesSteve Baker1-0/+2
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-09-30Allow enabling debug mode for config management (Puppet)Jiri Stransky1-0/+8
Also adds an environment file which can be passed to heat stack-create to enable debugging. Change-Id: I9758e2ca3de6a0bed6d20c37ea19e48f47220721 Depends-On: Ie92d1714a8d7e59d347474039be999bd3a2b542f
2015-06-16Make puppet-applying *Post resources depend on hieradataSteven Hardy1-0/+8
When you do a stack-update which affects, e.g ControllerDeployment such that some value in hieradata is updated (for example changing the "Debug" parameter to True), we only write the hieradata file and don't reapply the manifests. So we introduce a dependency on the deploy_stdout values from all hieradata applying configs, such that the manifests will be re-applied on update if the data is changed. This requires https://review.openstack.org/#/c/190282/ so that 99-refresh-completed will return the derived config ID as part of the deploy_stdout payload. Closes-Bug: #1463092 Change-Id: I1175248c3236d0c42e37d062afce550efce8aadc
2015-05-20Overcloud: bump HOT version to 2015-04-30Dan Prince1-1/+1
This patch bumps the HOT version for the overcloud to Kilo 2015-04-30. We should have already done this since we are making use of OS::stack_id (a kilo feature) in some of the nested stacks. Also, this will give us access to the new repeat function as well. Change-Id: Ic534e5aeb03bd53296dc4d98c2ac5971464d7fe4
2015-04-24Add hooks for extra post-deployment configSteven Hardy1-0/+9
Adds optional hooks which can run operator defined additional config on nodes after the application deployment has completed. Change-Id: I3f99e648efad82ce2cd51e2d5168c716f0cee8fe
2015-04-17Refresh description for swift/cinder/ceph storage nodesGiulio Fidente1-3/+1
These appear in the Tuskar UI and CLI so are worth keeping consistent with those of the controller/compute nodes Change-Id: I7cdd3a67d6f190f43e279fad0c4bf5f409d1e161
2015-03-18Update puppet post config to enable stepped deploymentsGiulio Fidente1-4/+3
The upcoming heat hook/breakpoint features will enable stepped deployments via setting stop points via the resource_registry. For this to work, we need hard dependencies between each step of the puppet deployments, because the current "soft" dependencies caused by the name property only influences the hook script application ordering, not the graph traversed by heat during deployment. Since removing the name: puppet_n completely removes some useful self- documenting context, move this to a resource naming convention, which should also be useful for heat hooks/breakpoints, as they are expected to support globbed specification of each step. Related heat patch (not yet landed, but this is not dependent on it): https://review.openstack.org/#/c/146123/ Change-Id: I05b02a46d4e80c08a308d033c33d4901c8f6c94e
2015-02-23ObjectStore: Exec puppet after all configurationDan Prince1-0/+42
This patch adds a new ObjectStoreNodesPostDeployment resource which can be used along with the environment file to specify a nested stack which is guaranteed to execute after all the ObjectStore config deployments have executed. This is really useful for Puppet in that Heat actually controls where puppet executes in the deployment process and we want to ensure puppet runs after all hiera configuration data has be deployed to the nodes. With the previous approach some of the data would be there, but allNodes data would not be guaranteed to be there in time. As os-apply-config (tripleo-image-elements) have their ordering controlled within the elements themselves an empty stubbed in nested stack has been added so that we don't break that implementation. Change-Id: I778b87a17d5e6824233fdf9957c76549c36b3f78