aboutsummaryrefslogtreecommitdiffstats
path: root/overcloud-without-mergepy.yaml
AgeCommit message (Collapse)AuthorFilesLines
2015-05-04Merge "Add support for Glance RBD backend"Jenkins1-0/+8
2015-05-04Add support for Glance RBD backendDan Prince1-0/+8
This patch adds support for a new GlanceBackend setting which can be set to one of swift, rbd, or file to control which Glance backend is configured for use by default. Change-Id: Id6a3fbc3477e85e8e2446e3dc13d424f9535d0ff
2015-05-01Revert "Keystone domain for Heat"Dan Prince1-2/+2
This reverts commit 7313930c22b9f18d67e630de084ffcc6fad5ebe7. Seeing errors when trying to create the keystone admin role with packages. (ImportError: No module named os_client_config) Change-Id: I78796598ccb8d2ffd6bfca85dce7d18dc0fd768e Related-bug: #1450786
2015-05-01Reuse the various service passwords as db passwords.Derek Higgins1-0/+1
We need to stop using "unset" as the password for all databases. Ideally we would add a "XxxxDSN" parameter (e.g. KeystoneDSN) but this wont work because we don't know the VirtualIP to pass in. Until we can come up with a better solution we should at least get rid of the "unset" passwords. Change-Id: I31f45912fa9c116ccdee010a2c5d91ea43a25671 Depends-On: I8ffe1eb481f615b0fbe127cd8107f1e70794c839
2015-04-30Merge "Keystone domain for Heat"Jenkins1-2/+2
2015-04-29Allow deployer to choose Ceilometer backendYanis Guenane1-0/+5
Ceilometer can use different backends. A recent change moved backend support for Ceilometer from MySQL to MongoDB. This commit introduce a greater flexibility, letting the deployer choose wheter MySQL or MongoDB should be used as a backend for Ceilometer. Change-Id: I0d5bfb0763cbcee234df7ab13574d866743d5ddf
2015-04-27puppet: install Horizon on overcloud-controllerEmilien Macchi1-0/+6
Install OpenStack Dashboad (Horizon) on the Overcloud Controller with Puppet. Co-Authored-By: Giulio Fidente <gfidente@redhat.com> Depends-On: If9b12d373e407be8be8428d77145f131eb450e88 Change-Id: I254e895014f58a51dade3dcdc63eabbb5dc458ac
2015-04-22Merge "Set EnablePacemaker == false be default"Jenkins1-1/+1
2015-04-22Set EnablePacemaker == false be defaultDan Prince1-1/+1
Pacemaker is a new feature and should probably be disabled by default. Change-Id: I840d08c9e0563aeb7128eb2b21929612b7a5bf7a
2015-04-22Keystone domain for HeatMartin Mágr1-2/+2
This patch adds support for configuring Keystone domain for Heat via heat-keystone-setup-domain script. It should be reverted as soon as Keystone v3 is fully functional. Change-Id: I7397f49fac17c30262d02b70021d613aef5c6cad
2015-04-21Parameter to enable/disable controller swift storeDan Prince1-0/+5
Adds a new ControllerEnableSwiftStorage parameter that can be used to enable/disable use of the contoller node as a Swift storage node. Change-Id: Ic54144f4a46a671818c2f12e419cfa619b0dc1f9
2015-04-21Add option to enable ceph storage on controllerDan Prince1-0/+5
This patch adds a new ControllerEnableCephStorage option which can be used to install and configure Ceph storage (OSD) on the controller node. The default is to have this disabled by default (this is probably a more production like setting). The motivation for this change is to help facilitate CI jobs which actually use Ceph. Right now we have an issue where once the Heat stack finishes Ceph is configured and ready, but Cinder volume (required by our CI devtest_overcloud.sh test) may or may not have had enough time to recognize the amount of storage on the remote Ceph storage nodes. Waiting another periodic cycle for Cinder volume to recognize the actual amount of storage on the remote OSD nodes would work but there isn't a good way to do this ATM. The right solution here is probably to implement Heat breakpoints in our CI. As we haven't quite landed that change, another option is to simply make the controller node also be a Ceph storage node. Since this runs as "step 2" within the controller it ensures that the OSD will be available and thus Cinder volume will register the correct amount of storage on startup. Enabling this feature also matches what we do with Swift storage on the Controller (although we should provide an option to actually disable this as well). Change-Id: Ic47d028591edbaab83a52d7f38283d7805b63042
2015-04-20Perform basic setup of Pacemaker cluster using puppet-pacemakerGiulio Fidente1-3/+9
Depends-On: Ia1bbf53c674e34ba7c70249895b106ec0af3c249 Change-Id: Ifa9f579d26a3cba9f8705226984c7b987ae0ad1c
2015-04-14Perform basic setup of pacemaker cluster on controllersGiulio Fidente1-0/+6
Change-Id: Ia2e4eae619ca95c0f417f713676732eb4f01304b Depends-On: I9563eec0a2266deb2ebef2e3d76ae89d39b2be29
2015-04-10MariaDB bind on correct addressJiri Stransky1-0/+5
Despite passing bind-address for MariaDB in overcloud_controller.pp correctly, it was always trying to bind on 0.0.0.0. The problem is caused by Galera's config file (we install Galera into the image even though we don't use it yet). Galera's default config file contains override of the bind-address value to 0.0.0.0, and the setting from galera.cnf took precendence over what was in server.cnf. The mariadb-galera-server package assumes that the main config happens in galera.cnf and it ships an almost empty server.cnf. We now have an EnableGalera param, when it's set to true the mysql module will manage galera.cnf instead of server.cnf, overriding the default values from galera.cnf and fixing the issue. Change-Id: I7c2fd41d41dcf5eb4ee8b1dbd74d60cc2cabeed9 Closes-Bug: #1442256
2015-04-09Pass in libvirt_rbd_secret_key for nova computeJiri Stransky1-1/+1
Passing the key explicitly into nova::compute::rbd means that Puppet will not attempt to fetch the key using `ceph auth get-key <keyring>`, having these effects: * One reason for compute node to have access to the client.admin key is gone (in current implementation it does have access to the key, but this change is a step towards removing it). * Ceph cluster doesn't have to be running at the time when Puppet runs on compute node, meaning we don't have to serialize things more than we do now. Also adding the ComputeCephDeployment as a dependency of ComputePostDeployment, otherwise the hiera file it creates might be created *after* Puppet configuration happens on compute nodes, and the values it provides would be missing during the Puppet run on the compute nodes. Change-Id: Id3166e6d5f01d18ec8a5033398bb511f4321a5e8 Depends-On: I70da06159c0d3c6fa204b5f7a468909ffab4d633 Partial-Bug: #1439949
2015-04-06Merge "Update descriptions comments for Ceph params"Jenkins1-3/+3
2015-04-02Update descriptions comments for Ceph paramsDan Prince1-3/+3
When trying out Ceph functionally the CephClusterFSID parameter must be a UUID. Additionally, the MonKey and AdminKey parameters should be generated via ceph-authtool (or equivalently generated) to ensure they work properly with the Ceph configuration. Change-Id: I0c327843ef225d330d1c668f53324973c78d3505
2015-04-02Provide a way to know the boostrap_nodeid IPYanis Guenane1-0/+1
Currently it is possible to know what is the hostname of the boostrap nodeid but not its IP. Since depending on the use case the use of the IP might be needed, a way to have access to this information should be provided. Change-Id: I9d0a7ee7de2088ddb87e0d8a8ae2b3ac75b0e78d
2015-04-01puppet: add debug mode for OpenStack servicesJiri Stransky1-0/+3
Propagate the top-level Debug parameter wherever it makes sense. Swift doesn't have this kind of debug setting, it only allows to configure log levels, so we'll need a different approach there. Change-Id: I15332315a2fbaeaf924cde4e748fb0e064a778b7
2015-04-01Merge "Ensure all Rabbit params are propagated to interested nodes."Jenkins1-1/+6
2015-03-25Implement mongo_node_ips hiera keyJiri Stransky1-0/+1
We need a list of hosts where MongoDB is supposed to run (as a list of IP addresses, not names) to implement MongoDB support in overcloud. Change-Id: I4b80f13be7e50630314d0642fa32b7763b6a2921
2015-03-19Add support for Neutron l3_ha option in puppet templatesGiulio Fidente1-0/+1
With this change we wire the NeutronL3HA parameter to the puppet class, where needed. Change-Id: I37b3850f71885a93859b5e51925df379616fc6ab
2015-03-19Ensure all Rabbit params are propagated to interested nodes.Giulio Fidente1-1/+6
Change-Id: I1bb8ee15d361638d77c5df7f8c03561c34f4c88f
2015-03-18Add support for Ceph as a Cinder and Nova backendYanis Guenane1-0/+16
This commit aims to add support for Ceph as a cinder and a nova backend. * Allows creation of Ceph pools from heat (Default: volumes, vms) * Creates the proper ceph user and inject the keys * Applies the proper configuration in cinder.conf and nova.conf * Enable the backend out of the box Co-Authored-By: Giulio Fidente <gfidente@redhat.com> Change-Id: Ic17d7a665de81a8bab5e34035abe90eda4bc889f
2015-03-16Merge "Make heat auth_encryption_key random"Jenkins1-0/+4
2015-03-13Make heat auth_encryption_key randomSteven Hardy1-0/+4
Currently we have a hard-coded default for auth_encryption_key, which isn't ideal as it's used as a salt for the DB encryption. Instead, reference an OS::Heat::RandomString resource so we create a random key for each deployment. Change-Id: Ic76b89db17603c114d98d28c01f75cc287fb2e90
2015-03-12Use Cinder multibackend by defaultYanis Guenane1-1/+8
Currently Cinder iscsi backend is configured within the DEFAULT section. Since we aim to support multibackend, this commit puts the iscsi backend in its own section and enable it by default configuring it properly. Also adds a parameter which can be used to disable the default backend. Co-Authored-By: Giulio Fidente <gfidente@redhat.com> Change-Id: I05fb44b59829c0afa8a6588956a48320f2f65159
2015-03-05Puppet: First support CephEmilien Macchi1-17/+50
This is a first implementation of Ceph support in TripleO with Puppet: * Install ceph-mon on controller node * Install ceph-osd on cephstorage node Co-Authored-By: Giulio Fidente <gfidente@redhat.com> Change-Id: I48488cbe950047fae5e746e458106d6edb9a6183
2015-02-23Add allNodesConfig to Swift storage nodesDan Prince1-1/+7
This patch applies the allNodesConfig data to swift storage nodes. This contains hosts information which could be useful. Change-Id: Iaccfdc698e371d6618d561c33f256ccc3c166fb7
2015-02-23BlockStore: Exec puppet after all configurationDan Prince1-0/+12
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
2015-02-23ObjectStore: Exec puppet after all configurationDan Prince1-0/+6
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 implementation. Change-Id: I778b87a17d5e6824233fdf9957c76549c36b3f78
2015-02-23Compute: Exec puppet after all configurationDan Prince1-0/+6
This patch adds a new ComputeNodesPostDeployment resource which can be used along with the environment file to specify a nested stack which is guaranteed to execute after all the Compute 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: I80bccd692e45393f8250607073d1fe7beb0d7396
2015-02-19Split out BootstrapNode SoftwareConfigDan Prince1-6/+3
This patch splits out the BootstrapNode config such that alternate implementation (puppet for example) can implement their own SoftwareConfig's via a nested stack. This is controlled by the standard overcloud heat environment. For os-apply-config deployments the implementation should work the same as before. For puppet deployments the implementation uses hiera metadata to configure bootstrap_nodeid. Change-Id: I691a9d7c474866038a5d47beab295899b5479d03
2015-02-13Split out allNodesConfig SoftwareConfigDan Prince1-32/+9
This patch splits out the allNodesConfig config such that alternate implementation (puppet for example) can implement their own SoftwareConfig's via a nested stack. This is controlled by the standard overcloud heat environment. For os-apply-config deployments the implementation should work the same as before. For puppet deployments the implementation uses hiera metadata to configure rabbit_nodes. The puppet deployment doesn't support hosts, or freeform sysctl metadata yet so those are the same for now as well. Change-Id: I34ae30b1f37aca8b39586f7e350511462d66f694
2015-02-12Split out SwiftDevicesAndProxy SoftwareConfigDan Prince1-19/+6
This patch splits out the SwiftDevicesAndProxy config such that alternate implementation (puppet for example) can implement their own SoftwareConfig's via a nested stack. This is controlled by the standard overcloud heat environment. For os-apply-config deployments the implementation should work the same as before. For puppet deployments the implementation uses hiera metadata to configure swift devices. Partial-bug: 1418805 Change-Id: Ibf6038460f36279ad51a04947589d4a03a553f66
2015-02-12Controller: Exec puppet after all configurationDan Prince1-0/+6
This patch adds a new ControllerNodesPostDeployment resource which can be used along with the environment file to specify a nested stack which is guaranteed to execute after all the Controller config (HA, or other) 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 most of the HA data which actually gets composed outside of the controller-puppet.yaml nested stack 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. Partial-bug: 1418805 Change-Id: Icd6b2c9c1f9b057c28649ee3bdce0039f3fd8422
2015-02-09Add Ceph related templates needed to configure Cinder with CephGiulio Fidente1-1/+41
The new ceph-source.yaml file provides the config settings needed by the elements which configure Ceph on controllers (monitors) and storage nodes (OSDs) as well as the Cinder backend which uses it. There is also a without-mergepy copy named ceph-storage.yaml Change-Id: I954861536c41b2a7e6cbd86a0f0b55004eed4c70
2015-02-04Puppet: Ntp supportDan Prince1-0/+2
This patch adds NTP support to all roles. As part of this change overcloud-without-mergepy.yaml has also been updated so that it passes the NtpServer parameters into the Swift and Cinder storage node templates so that Ntp can also be configured on those machines as well. NOTE: The puppet support here uses the puppetlabs-ntp modules which we add in Ib10ccbfdb3140b19f40049707548c6655d250e1c. Change-Id: If2ef236fa42a714e84c6944eee5fe4daddf3fedf
2015-01-27Remove unused cinder params from -without-mergepyDan Prince1-2/+0
Cinder block storage nodes shouldn't need to know the AdminPassword and CinderPassword values. There are no services which require Keystone related passwords on the block storage nodes. Change-Id: I4aa89347c60ec6258bd66725a895f6fd2b4844f6
2015-01-27Swift: set default replicas to 3Dan Prince1-1/+1
Our existing default (replicas == 1) means that no data (or copies) is being replicated in a multi-node Swift environment. This seems like a bad production default setting and could easily slip by if not set. Setting it to 3 shouldn't hurt anything and seems to follow suit with what several production installers (based around Puppet) actually use. If using an installation with less than 3 swift nodes I believe swift will do its best, and still work fine. FWIW I noticed this when testing a multi-node Puppet swift installation and was surprised when I didn't see any *data files getting replicated across the storage cluster. Change-Id: I44bdfff7aae6bdf845b79ca1f8f450c22113caed
2015-01-27Remove unused swift params from -without-mergepyDan Prince1-4/+0
In doing the Puppet version of the Swift role I noticed 4 parameters which we apply to storage nodes which should not be required. This patch drops the following parameters from the swift-storage and swift-storage-puppet nested stacks which should not be required. 1) ControllerIP: There is no reason a storage node should need the IP address of the controller. The swift proxy would need this information in order to be able to contact keystone. This swift-proxy is not installed on storage nodes so we can drop the parameter here. 2) NeutronEnableTunnelling: There is no reason for Neutron to be installed on Swift storage nodes. No need to create an OVS bridge either. 3) NeutronNetworkType: Similar to above. No neutron requirements exist here so this parameter is not required. 4) Password: This only applies to the the swift-proxy which is currently part of our controller role. Storage nodes shouldn't need the keystone service-password for any reason. Change-Id: Icbf05363475c388fc722277da3d3d00a7355b19a
2015-01-27Merge "Add parameter to manage usage of Neutron l3_ha option"Jenkins1-0/+6
2015-01-09Merge "Add SwiftMountCheck to overcloud-without-mergepy"Jenkins1-0/+6
2015-01-09Merge "Add SwiftMinPartHours to overcloud-without-mergepy"Jenkins1-0/+6
2015-01-09Add parameter to manage usage of Neutron l3_ha optionGiulio Fidente1-0/+6
This change will allow for the enablement of Neutron routers HA via the new NeutronL3HA parameter. Change-Id: Ia5f7c0b4e89159456482e840c50d166ec5f25d4c Implements: blueprint tripleo-icehouse-ha-production-configuration
2015-01-09Add SwiftMountCheck to overcloud-without-mergepyDan Prince1-0/+6
This was added in I36fece56bafa9fe9c4883b572687b3fc819eeae1 and is missing from overcloud-without-mergepy. Change-Id: I5c2566cc77247574f8d687eaab8094de481a8c67
2015-01-09Add SwiftMinPartHours to overcloud-without-mergepyDan Prince1-0/+6
This was added in Icc5e431a7e2884b3ca3a255b6fd901619bc98460 and is missing from overcloud-without-mergepy. Change-Id: I1273b646c04783712fd3f8baccafead11817689c
2015-01-09Merge "Default BlockStorageCount to 0 for without-mergepy jobs"Jenkins1-1/+1
2015-01-08Default BlockStorageCount to 0 for without-mergepy jobsGiulio Fidente1-1/+1
We have never created these additional storage nodes by default with the old templates; we agreed on adding a job for this in CI [1] so we will override the default value in the specific CI job. 1. https://github.com/openstack-infra/tripleo-ci/blob/master/docs/wanted_ci_jobs.csv Change-Id: Iaec38807bc209fc28d83e3d6922269e803110053