aboutsummaryrefslogtreecommitdiffstats
path: root/puppet/controller-post.yaml
AgeCommit message (Collapse)AuthorFilesLines
2016-05-19Tighten the access rules for galeraMichele Baldessari1-2/+0
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
2016-05-10deployment: drop step6Emilien Macchi1-12/+1
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
2016-05-10deployment: remove Step7Emilien Macchi1-12/+1
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
2016-03-31Configure ControllerServices via resource chainsDan Prince1-1/+6
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
2016-03-25Increment step count to include ringbuilderDan Prince1-22/+20
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
2016-02-26Add support for DeployArtifactURLsDan Prince1-1/+10
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
2016-01-18Merge "Set the name property for all deployment resources"Jenkins1-0/+6
2015-12-14Pacemaker maintenance mode for the duration of Puppet run on updateSteven Hardy1-1/+17
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>
2015-12-10Set the name property for all deployment resourcesSteve Baker1-0/+6
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/+5
Also adds an environment file which can be passed to heat stack-create to enable debugging. Change-Id: I9758e2ca3de6a0bed6d20c37ea19e48f47220721 Depends-On: Ie92d1714a8d7e59d347474039be999bd3a2b542f
2015-09-22Rename -puppet.yaml templates.Dan Prince1-0/+102
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