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
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
|
|
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
|
|
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
|
|
Wires the steps into the BlockStorage role and ensures
the installed-packages list is written on a per-step basis on
all roles, as it happens on the controllers already.
Change-Id: Iaec8ad3b2afbef6d586b7b46abaa1434cdb62f41
|
|
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
|
|
|
|
The ExtraConfig resource was missing from the cinder
storage role. Adding it for consistency.
Change-Id: I05ad33c113af6f67ded7699976103508c47a3f1a
|
|
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
|
|
Also adds an environment file which can be passed to heat stack-create
to enable debugging.
Change-Id: I9758e2ca3de6a0bed6d20c37ea19e48f47220721
Depends-On: Ie92d1714a8d7e59d347474039be999bd3a2b542f
|
|
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
|
|
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
|
|
These appear in the Tuskar UI and CLI so are worth keeping
consistent with those of the controller/compute nodes
Change-Id: I7cdd3a67d6f190f43e279fad0c4bf5f409d1e161
|
|
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
|
|
This patch adds a new BlockStoreNodesPostDeployment resource
which can be used along with the environment file to
specify a nested stack which is guaranteed to execute
after all the BlockStore 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: I29b3574e341eecd53b2867788f415bff153cfa9f
|