| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
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
|
|
Set a password for the 'root' db user and add an additional
'clustercheck' user to be used only by the resource agent.
The password for this 'clustercheck' user is randomly generated
via a heat parameter.
Before this change the workflow to set up the database in the
manifest is the following:
- Step 1 -> Install all the basic galera packages and basic configuration
- Step 2.a -> Create /etc/sysconfig/clustercheck with root and empty password
- Step 2.b -> Start up galera-monitor xinetd service
- Step 2.c -> Start pacemaker ocf resource (no root user has been created
so there will be an empty password per default)
- Step 2.d -> Wait for /bin/clustercheck to return success and then
proceed with the other steps
After this change the workflow is slightly more complex because there
is a bit of a chicken and egg problem:
- Step 1 -> Install all the basic galera packages and basic configuration
- Step 2.a -> Create /etc/sysconfig/clustercheck with root and empty
password unless the file does exists already and has a clustercheck user
configured
- Step 2.b -> Start up galera-monitor xinetd service
- Step 2.c -> Start pacemaker ocf resource (no root user has been created
yet, so there will be an empty password per default)
- Step 2.d -> Wait for /bin/clustercheck to return success and then proceed
with the other steps
- Step 2.e -> Create clustercheck db user
- Step 3/4 -> Create /etc/sysconfig/clustercheck with clustercheck user credentials
- Step 5.a -> Update the sql root password on the each node (at this
stage
- Step 5.b -> Create /root/.my.cnf with proper credentials on all nodes
Note that we cannot really create the root/clustercheck users right at
step 1 because the db is not running yet (an approach that spawned
mysqld on each node, created the users and shut it down, was tried but
was much more complex and cannot work on updating existing setups)
Given the new way of solving the root password issue, we also need to
make sure that Step1 and Step2 are running on updates.
Closes-bug: #1581677
Depends-On: I83eed8885503043e881db34411616f9726e00352
Change-Id: If3d6e7253af6195b96129be7ea3348d697e4bae1
|
|
Step6 was just about confuring fencing after creating all Pacemaker
resources.
It was created by this patch:
https://review.openstack.org/#q,1787fbc7ca58f9965cd5d64b685c1f9beed4cb9b,n,z
A bit of Puppet orchestration can help us to not require an extra step.
This patch:
* configure & enable fencing at step5
* make sure we don't configure fencing because creating Pacemaker
resources and constraints.
* remove step6 from deployment workflow.
* depends on a patch in puppet-tripleo that moves keystone resources
(endpoints, roles) to step 5.
Change-Id: Iae33149e4a03cd64c5831e689be8189ad0cf034b
Depends-On: Icea7537cea330da59fe108c9b874c04f2b94d062
Depends-On: I079e65f535af069312b602e8ff58be80ab2f2226
|
|
Step7 was created when we incremented the step of ringbuilder, by
https://review.openstack.org/#q,9988bd25aa4bac1375ef4783d636c7adecedee92,n,z
But step7 is not used anywhere and consumes some times for nothing.
This patch removes the step, so deployments and upgrades will be faster.
Change-Id: I77af9126abc61ace227cf1a69c2d3b5ceb735276
|
|
This patch wires in a new for Mitaka Heat feature
that allows us to dynamically include a set of nested
stacks representing individual services via a Heat resource chain.
Follow on patches will use this interface to decompose the controller
role into isolated services.
Co-Authored-By: Steve Hardy <shardy@redhat.com>
Depends-On: If510abe260ea7852dfe2d1f7f92b529979483068
Change-Id: I84c97a76159704c2d6c963bc4b26e365764b1366
|
|
This patch wires in ringbuilder.pp so that it is always
asserted like the other manifests and it fixes the misaligned
step sequencing in calling our overcloud controller manifests.
Previously it was called as a separate software deployment outside of
the hiera step sequence. This made things confusing in
controller-post.yaml since the deployment names didn't align
with the step hiera variables after step 3. Now that we call it
just like the other modules it should make gradually moving this
code to puppet-tripleo more straightforward as well.
Change-Id: Ibd4f51f65da475bb20a6b08d7bda673f330a5464
|
|
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
|
|
|
|
This enables pacemaker maintenantce mode when running Puppet on stack
update. Puppet can try to restart some overcloud services, which
pacemaker tries to prevent, and this can result in a failed Puppet run.
At the end of the puppet run, certain pacemaker resources are restarted
in an additional SoftwareDeployment to make sure that any config changes
have been fully applied. This is only done on stack updates (when
UpdateIdentifier is set to something), because the assumption is that on
stack create services already come up with the correct config.
(Change I9556085424fa3008d7f596578b58e7c33a336f75 has been squashed into
this one.)
Change-Id: I4d40358c511fc1f95b78a859e943082aaea17899
Co-Authored-By: Jiri Stransky <jistr@redhat.com>
Co-Authored-By: James Slagle <jslagle@redhat.com>
|
|
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
|
|
Updates the /puppet directory templates so that we drop the
'-puppet' from the filenames. This is redundant because
we already have puppet in the directory name and fixes
inconsistencies where we aren't using -puppet in
all the files within the puppet directory.
Depends-On: I71cb07b2f5305aaf9c43ab175cca976e844b8175
Change-Id: I70d6e048a566666f5d6e5c2407f8a6b4fd9f6f87
|
Steven Hardy
Dan Prince
Michele Baldessari
Emilien Macchi
Jenkins
Steve Baker
Jiri Stransky