|Age||Commit message (Collapse)||Author||Files||Lines|
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
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.
This moves the ringbuilder puppet code to puppet-tripleo
and migrates to the composable services format.
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.
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.
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
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
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
Partially-Implements: blueprint composable-services-within-roles
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.
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
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.
Implements: blueprint puppet-modules-deployment-via-swift
There are two reasons the name property should always be set for deployment
- 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
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
Also adds an environment file which can be passed to heat stack-create
to enable debugging.
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
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.
Adds optional hooks which can run operator defined additional config on
nodes after the application deployment has completed.
These appear in the Tuskar UI and CLI so are worth keeping
consistent with those of the controller/compute nodes
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):
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