aboutsummaryrefslogtreecommitdiffstats
path: root/puppet/objectstorage-role.yaml
AgeCommit message (Collapse)AuthorFilesLines
2017-06-14Add fqdn_externalAlex Schultz1-0/+1
In newton, we used to construct the fqdn_$NETWORK in puppet-tripleo for external, internal_api, storage, storage_mgmt, tenant, management, and ctrlplane. When this was moved into THT, we accidently dropped external which leads to deployment failures if a service is moved to the external network and the configuration consumes the fqdn_external hiera key. Specifically this is reproduced if the MysqlNetwork is switch to to exernal, then the deployment fails because the bind address which is set to use fqdn_external is blank. Change-Id: I01ad0c14cb3dc38aad7528345c928b86628433c1 Closes-Bug: #1697722 (cherry picked from commit 426de202880c890360bd446907aca44ca1e73a03)
2017-04-20SSH known_hosts configOliver Walsh1-0/+37
Fetch the host public keys from each node, combine them all and write to the system-wide ssh known hosts. The alternative of disabling host key verification is vulnerable to a MITM attack. Change-Id: Ib572b5910720b1991812256e68c975f7fbe2239c (cherry picked from commit 7d3552a105ad5aa62cad0998c11df5ec6bd06ed6)
2017-03-03Make UpdateDeployment depend on NetworkDeploymentSteven Hardy1-0/+1
Prior to https://review.openstack.org/#/c/271450/ os-net-config was applied via os-refresh-config directly, which meant that even though UpdateDeployment and NetworkDeployment can be created concurrently, we'd always do the os-net-config step first. However now that we apply both steps via scripts (which are both handled via the same heat-config hook) we should add an explicit dependency to ensure the network is always fully configured before attempting to run any update. This should avoid the risk of e.g running an update on initial deployment before the network connectivity to access yum repos is in place. Change-Id: Idff7a95afe7b49b6384b1d0c78e76522fb1f8eb7 Related-Bug: #1666227 (cherry picked from commit 626b820b57498ff5002c5530962e6e4fd5644b51)
2017-02-17Add Newton to Ocata UpgradeInitCommonCommandmarios1-0/+9
This adds the UpgradeInitCommonCommand for newton..ocata common UpgradeInit commands. This comes before the ansible upgrade steps so we need to do things like remove the old newton hieradata and install the ansible-pacemaker module and ansible heat-agent plugin This defaults to '' and is set in the major-upgrade-composable-steps and unset in the major-upgrade-converge environment files. Change-Id: I0c7a32194c0069b63a501a913c17907b47c9cc16 (cherry picked from commit 01a91d37199f592aa4273e3847eb1f4f1d27da02)
2017-01-04Merge "Add pre-network hook and example showing config-then-reboot"Jenkins1-0/+6
2016-12-23Bump template version for all templates to "ocata"Steven Hardy1-1/+1
Heat now supports release name aliases, so we can replace the inconsistent mix of date related versions with one consistent version that aligns with the supported version of heat for this t-h-t branch. This should also help new users who sometimes copy/paste old templates and discover intrinsic functions in the t-h-t docs don't work because their template version is too old. Change-Id: Ib415e7290fea27447460baa280291492df197e54
2016-12-22Merge "Introduce role-specific NodeUserData, use for docker"Jenkins1-0/+7
2016-12-22Add hook to generate metadata from service profilesJuan Antonio Osorio Robles1-0/+4
This enables the deployer to dynamically add nova metadata to the servers based on the output of service profiles that implement the metadata_settings key in the role_data output for the profiles. One can set an implementation via the OS::TripleO::ServerMetadataHook resource, which currently is set as OS::Heat::None. So, because of the default implementation, if left untouched it actually does nothing. Currently, besides the list, which is metadata_settings, this hook also takes the name of the node that it's setting the metadata for. This is useful for nova vendordata plugins that can parse said metadata. Change-Id: I8a937f711f0b90156fbb6c4632760435ef846474
2016-12-19Introduce role-specific NodeUserData, use for dockerSteve Baker1-0/+7
Currently when the docker environments are invoked, every node has the boot script run which replaces os-collect-config with the heat-agents container. This should only be happening on Compute nodes currently, and each role will be converted to heat-agents one at a time. This change implements a role-specific NodeUserData resource and uses that mechanism to run docker/firstboot/install_docker_agents.yaml only on Compute nodes. Change-Id: Id81811dbcaf0e661c3980aa25f3ca80db5ef0954
2016-12-19Move UpgradeInitCommand to role templatesSteven Hardy1-1/+28
We can't run this during the upgrade steps, because there are things which need to happen before any role configuration happens, e.g installing the new hiera heat-config hook, which must be done before e.g "ControllerDeployment" runs or the stack update hangs. Partially-Implements: blueprint overcloud-upgrades-per-service Change-Id: I365b57513590662c3f78a33dc625747f457c48c5
2016-12-16Introduce role-specific nova-server-metadataJuan Antonio Osorio Robles1-2/+14
We could already pass metadata to the nova server instances (on creation) via the ServerMetadata parameter, however, there was no way of doing this per-role. This introduces that by adding a {{role}}ServerMetadata parameter for each role. This parameter gets merged with the ServerMetadata parameter and allows this functionality. Note that both default to {}, and so does the result of merging those parameters with their default values. So nothing changes for the default settings. Change-Id: I334edcc51ce7ee82fc13b6cf4c0d74ccb7db099c
2016-12-15Add pre-network hook and example showing config-then-rebootSteven Hardy1-0/+6
There are some requirements for early configuration that involves e.g setting kernel parameters then rebooting. Currently this can be done via cloud-init, e.g firstboot templates, but there's been discussion around enabling a SoftwareDeployment approach instead. The main advantage of doing it this way is there's an error path if something goes wrong with the config (except triggering the reboot as we have to use NO_SIGNAL for that). Change-Id: Ia54ee654f755631b8062eb5c209a60c6f9161500
2016-12-06Fix SwiftStorage role.Chris Jones1-2/+2
We now fetch the name argument from the correctly named SwiftStorage object. Change-Id: I885505eadfc778ab57793c97af4d1c6739ec9614 Closes-Bug: #1647716
2016-12-02Move nodes' fqdns to a map to remove clutterJuan Antonio Osorio Robles1-114/+110
There were several instances where the short-names/FQDNs where being gotten in the same way in the role's templates. So this introduces a mapping to get these values in order to reduce clutter. Change-Id: Ie7df360bb69d56655f3e0fcbbf4d297db39b7a26
2016-12-01Introduce network-based FQDNs via hieraJuan Antonio Osorio Robles1-0/+37
Currently, one can get the network-based FQDNs via a custom puppet fact. This is currently unreliable, as it's based on the ::hostname fact which we assume it's set correctly by nova. However, this is not necessarily the case (for instance, if you use pre-deployed services such as we do with the multinode-jobs). In these cases, the ::hostname fact will return something other than what we specified in nova, and effectively breaks the configurations in we relly too much on the network-based FQDN facts. By using hiera instead, we avoid this issue as we set those values to be exactly what we expect (as we set them in the OS::TripleO::Server resource. Change-Id: I6ce31237098f57bdc0adfd3c42feef0073c224fb
2016-11-30Hiera optimization: use a new hiera hookDan Prince1-33/+26
This patch optimizes how we deploy hiera by using a new heat hook specifically designed to help compose hiera within heat templates. As part of this change: - we update all the 'hiera' software configurations to set the group to hiera instead of os-apply-config. - The new format uses JSON instead of YAML. The hook actually writes out the hiera JSON directly so no conversion takes place. Arrays, Strings, Booleans all stay in their native formats. As such we can avoid having to do many of the awkward string and list conversions in t-h-t to support the previous YAML formatting. - The new hook prefers JSON over YAML so upgrading users will have the new files prefered. (we will post a cleanup routine for the old files soon but this isn't a new behavior, JSON is now simply prefered.) - A lot of services required edits to account for default settings that worked in YAML that no longer work correctly in the native JSON format. In almost all these cases I think the resulting codes looks cleaner and is more explicit with regards to what is getting configured in hiera on the actual nodes. Depends-On: I6a383b1ad4ec29458569763bd3f56fd3f2bd726b Closes-bug: #1596373 Change-Id: Ibe7e2044e200e2c947223286fdf4fd5bcf98c2e1
2016-11-22Make the CloudDomain defaults match the doc stringsJulie Pichon1-0/+1
Not having the default easily accessible is causing issues for the UI, as it cannot guess at it and can accidentally overwrite the value with an empty string (the expected default when unset). The default is already helpfully spelled out in the doc string for each file, this updates the parameter to match it. Change-Id: Ic284f9904e8f1d01cc717d59a0759f679d94106d Closes-Bug: #1643670
2016-10-06Merge "restore missing fluentd client functionality"Jenkins1-8/+0
2016-10-05restore missing fluentd client functionalityLars Kellogg-Stedman1-8/+0
in the great rebase following the JINJA ALL THE THINGS changes we lost critical functionality in the fluentd client service. This review restores the missing features. Change-Id: I7c23f16f81e75f3da6a24587b2eb8385b3e920a4 Closes-bug: 1630692
2016-10-05Select per-network hostnames for service_node_namesSteven Hardy1-0/+45
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com> Depends-On: Ic6fec1057439ed9122d44ef294be890d3ff8a8ee Change-Id: I754c4a41d8a294a4c7c18bd282ae014efd4b9b16 Closes-Bug: #1628521
2016-10-04Move the main template files for defalut services to new syntax generationCarlos Camacho1-0/+396
When generating these templates, we should create them with the "-role" appended as they will be generated from a role.role.j2.yaml file. i.e. role.role.j2.yaml will generate <service>-role.yaml config.role.j2.yaml will generate <service>-config.yaml Partial-Bug: #1626976 Change-Id: I614dc462fd7fc088b67634d489d8e7b68e7d4ab1