summaryrefslogtreecommitdiffstats
path: root/puppet/all-nodes-config.yaml
AgeCommit message (Collapse)AuthorFilesLines
2016-08-12Remove deprecated node_ips hiera keysSteven Hardy1-32/+0
This aligns with the new naming conventions in puppet-tripleo, so the keys can be more easily generated from the service_names. Change-Id: Idb4a740e70257e3c69d8ec7d0c88594cc091b6a7 Partially-Implements: blueprint custom-roles Depends-On: I423b544df174254ac511b906b0c570e701678022
2016-08-11Align node_ips hiera keys with the service name.Steven Hardy1-1/+33
To enable composable generation of this switch the key names to align with the service_name of each service. Note that this should depend on I423b544df174254ac511b906b0c570e701678022 and previously passed CI with that defined, but because we now run gate validation jobs on puppet-tripleo it's impossible to land, so this now contains both old and new hiera keys temporarily, which will be removed when the puppet-tripleo patch lands. Change-Id: I7febf28bf409e25e8e5961ab551b6d56bb11e0c6 Partially-Implements: blueprint custom-roles
2016-08-08Merge "Convert AllNodesConfig hosts config to a map"Jenkins1-24/+2
2016-08-02Enable Manila integration - as a composable controller serviceRyan Hefner1-0/+11
Allows the installation and configuration of Manila. Supports the generic driver only. This has a dependency on the puppet-tripleo classes for manila where the puppet specific config now lives. The review at https://review.openstack.org/#/c/315658/ has been merge into this one, as of v68, so manila lands as a composable service. This was brought up on the mailing list at [1] [1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/096126.html Co-Authored-By: Marios Andreou <marios@redhat.com> Implements: blueprint composable-services-within-roles Depends-On: I444916d60a67bf730bf4089323dba1c1429e2e71 Depends-On: I9eda4b3364e5c59342761a1ec71b0eb567c69cf1 Depends-On: I571b65a5402c1028418476a573ebeb9450ed00c9 Change-Id: I7acebac4354fca1f8d7ff6c343c1346bf29b81c6
2016-07-29Convert AllNodesConfig hosts config to a mapSteven Hardy1-24/+2
Currently we have hard-coded parameters for each role, but to enable custom roles, we need to pass a generic hosts list that can be joined for all enabled roles. Change-Id: I0606f462ff61c3a541342b63fee7d46ebfd1f4e0 Partially-Implements: blueprint custom-roles
2016-07-27Migrate Puppet Hieradata to composable servicesEmilien Macchi1-2/+0
Migrate puppet/hieradata/*.yaml parameters to puppet/services/*.yaml except for some services that are not composable yet. Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com> Change-Id: I7e5f8b18ee9aa63a1dffc6facaf88315b07d5fd7
2016-07-05Combine BootstrapNodeDeployment with AllNodesDeploymentSteven Hardy1-0/+4
Currently we have a special controller-only deployment which writes the name/ip of the "bootstrap node", e.g the cluster master, which defaults to the first node in the Controller ResourceGroup. Now we're moving to fully composable services/roles, it's possible folks will want to deploy services that expect to detect the bootstrap node (e.g so only one node does a DB sync) for non-controller roles. So, take this opportunity to combine the bootstrap node deployment with the "all nodes" data, such that we deploy the same data for all roles. Because the boostrap node data is per role cluster, rather than truly global, we pass it via input_values into each per-role Deployment. At some future point we might consider renaming this, e.g to something which describes per-cluster config vs "all nodes", but as a first step let's just rationalize the resources. Change-Id: I4011526a13c51b3d0f95c17fe8ed38115b4fdce4
2016-07-04Switch Ceph Monitor/OSD/Client/External to composable rolesGiulio Fidente1-1/+20
Change-Id: I1921115cb6218c7554348636c404245c79937673 Depends-On: I7ac096feb9f5655003becd79d2eea355a047c90b Depends-On: I871ef420700e6d0ee5c1e444e019d58b3a9a45a6
2016-06-29Basic support for deploying Ironic in overcloudImre Farkas1-0/+11
Note that this change is not enough yet to deploy bare metal instances, it only deploys Ironic services themselves and makes sure they work. Also it does not support HA for now. Co-Authored-By: Dmitry Tantsur <dtansur@redhat.com> Partially-implements: blueprint ironic-integration Change-Id: I541be905022264e2d4828e7c46338f2e300df540
2016-05-04Merge "Fix distinguishing between stack-create and stack-update"Jenkins1-0/+7
2016-04-11Deploy Gnocchi as a Ceilometer metrics storage backendPradeep Kilambi1-0/+10
* Deploy Gnocchi API. * Storage backends: swift, rbd and file. * Indexer backend default to mysql * Configure Ceilometer to send metrics datas to Gnocchi * Pacemaker config Depends-On: Ic8778a3104e0ed0460423e4bf857682220dc5802 Depends-On: I7d2eb9405e0171fc54fa0b616122f69db5f51ce2 Co-Authored-By: Pradeep Kilambi <pkilambi@redhat.com> Change-Id: Ifde17b1ab8fa2b30544633e455e1c7eb475705aa
2016-04-11Fix distinguishing between stack-create and stack-updateJiri Stransky1-0/+7
Previously we tried to use UpdateIdentifier for two different things: tell whether to perform package update, and also to tell whether the top-level stack is being created or updated (which was incorrect and resulted in bug 1567384, and an attempt to work around that bug resulted in bug 1567385). We cannot use Heat's "action" conditionals in some cases, because they refer to the direct parent stack, which can yield undesirable results when introducing new nested stacks or temporarily no-opping something and then adding it back (in both these cases, "action" would be considered "CREATE", even though the top-level stack is in "UPDATE"). So tripleoclient passes a new parameter StackAction to tell whether the top-level stack is being created or updated, and we make use of that. (It seems there's no better way of getting this info from within the nested Heat stacks.) Change-Id: Ie14ddbff15e7ed21aaa3fcdacf36e0040f912382 Depends-On: I9dc3b4cd8a6a71df34d8babf0e4c6505041f5311 Closes-Bug: #1567384 Related-Bug: #1567385
2016-03-20Deploy Aodh services, replacing Ceilometer AlarmPradeep Kilambi1-0/+11
Ceilometer Alarm is deprecated in Liberty by Aodh. This patch: * manage Aodh Keystone resources * deploy Aodh API under WSGI, Notifier, Listener and Evaluator * manage new parameters to customize Aodh deployment * uses ceilometer DB for the upgrade path * pacemaker config * Add migration logic to remove pcs resources Depends-On: I5333faa72e52d2aa2a622ac2d4b60825aadc52b5 Depends-On: Ib6c9c4c35da3fb55e0ca8e2d5a58ebaf4204d792 Co-Authored-By: Emilien Macchi <emilien@redhat.com> Change-Id: Ib47a22884afb032ebc1655e1a4a06bfe70249134
2016-03-08Merge "Fixup the memcached servers string in nova.conf for v6"Jenkins1-0/+8
2016-03-07Merge "Fix rabbit_hosts list for glance-api for IPv6"Jenkins1-0/+1
2016-03-07Fixup the memcached servers string in nova.conf for v6marios1-0/+8
As discussed at https://bugzilla.redhat.com/show_bug.cgi?id=1299265 when providing a list of IPv6 addresses as the memcache_node_ips the resulting nova.conf entry can't be parsed properly. This adds a memcache_node_ips_v6 which has the required format like inet6:[ADDR1],inet6:[ADDR2],inet6:[ADDR3] Closes-Bug: 1536103 Change-Id: I7f95fa063cbba279c4c2e270841f0a279d2be2f6
2016-03-04Revert "Deploy Aodh services, replacing Ceilometer Alarm"James Slagle1-11/+0
This just a revert to see if reverting this gets back to a normal CI run time. This reverts commit f72aed85594f223b6f888e6d0af3c880ea581a66. Change-Id: I04a0893f6cf69f547a4db26261005e580e1fc90b
2016-03-05Fix rabbit_hosts list for glance-api for IPv6Giulio Fidente1-0/+1
Previously we were always appending the :port suffix to the list of rabbitmq nodes but the syntax was invalid for IPv6. This change wires rabbit_hosts from the templates as it happens already for the other services. Port can be customized using rabbit_port. Change-Id: Iecc7a97d46d7de17e85398c57996c104c9125b0e
2016-03-03Deploy Aodh services, replacing Ceilometer AlarmEmilien Macchi1-0/+11
Ceilometer Alarm is deprecated in Liberty by Aodh. This patch: * manage Aodh Keystone resources * deploy Aodh API under WSGI, Notifier, Listener and Evaluator * manage new parameters to customize Aodh deployment * uses ceilometer DB for the upgrade path * pacemaker config Depends-On: I9e34485285829884d9c954b804e3bdd5d6e31635 Depends-On: I891985da9248a88c6ce2df1dd186881f582605ee Depends-On: Ied8ba5985f43a5c5b3be5b35a091aef6ed86572f Co-Authored-By: Pradeep Kilambi <pkilambi@redhat.com> Change-Id: I58d419173e80d2462accf7324c987c71420fd5f6
2016-02-10Merge "Remove not needed completion-signal"Jenkins1-1/+1
2016-01-20Fix MidoNet errorsJaume Devesa1-0/+9
Some assignments must be fixed in order to make run midonet with HA pacemaker properly and when the network isolation is enabled. Change-Id: I69fb3a1911cfe3baea3349da8f3e185dddf60a95
2016-01-08Sahara IntegrationEthan Gafford1-0/+11
Integration of OpenStack data processing service (sahara) with TripleO. - Deploys sahara in distributed mode (separate api and engine processes on each controller node) - Load balancing w/haproxy - RabbitMQ/MySQL supported per current TripleO standard - Minimal configurability at this time Change-Id: I77a6a69ed5691e3b1ba34e9ebb4d88c80019642c Partially-implements: blueprint sahara-integration Depends-On: I0f0a1dc2eaa57d8226bad8cfb250110296ab9614 Depends-On: Ib84cc59667616ec94e7edce2715cbd7dd944f4ae Depends-On: I9fe321fd4284f7bfd55bd2e69dcfe623ed6f8a2a
2016-01-08Remove not needed completion-signalSteven Hardy1-1/+1
The completion-signal input is no longer needed, because for some time 99-refresh-completed has supported using per-deployment signal URLs instead provided the config group is set correctly to os-apply-config. Change-Id: I76cb5331917ff54e978bd22b9dea0c1a2c65a928
2015-12-18Merge "Fix typo in HostsEntry output description"Jenkins1-1/+1
2015-12-15Merge "Pacemaker maintenance mode for the duration of Puppet run on update"Jenkins1-0/+14
2015-12-15Fix typo in HostsEntry output descriptionJuan Antonio Osorio Robles1-1/+1
Change-Id: I72a79d8200adee8258033e8da370051bbfd1986b
2015-12-14Pacemaker maintenance mode for the duration of Puppet run on updateSteven Hardy1-0/+14
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-04Add output for host entriesJuan Antonio Osorio Robles1-0/+6
For testing purposes it is useful to have an easy way to get the given IPs for the nodes; since currently one would have to ssh to one of the ndoes and actually fetch the entries from there. This will facilitate testing when the keystone endpoints have been changed for hostnames, as done in this CR: https://review.openstack.org/#/c/238887 Change-Id: I9b9362192d7e97690ba23d02e74389225913adb9
2015-08-18Enable Keystone notificationsGiulio Fidente1-0/+1
This change enables Keystone notifications and adds two parameters to control the notification driver and format. Change-Id: I23ac3c46ee9eb49523d3b8dab027ef21fc6e42df
2015-06-24Set MariaDB package name in RedHat.yamlDan Prince1-0/+2
This moves the hard coded package name for mariadb into the RedHat specific hieradata file. This was recently added to controller.yaml in a1b3fa3e84185b6969a8acfda475fe7fc48bd5a1. Also, resolves an issue where RedHat.yaml wasn't actually getting deployed. This is something that should have happened in 5009cc64322e9fb5723799eb9fbd79076a2dc5da. Change-Id: Iaa30be3c53a7c54d31d47b997966b0106a202ea4
2015-06-03Make all-nodes Ip networks configurableDan Prince1-10/+161
This patch adds a new NetIpListMap abstraction which we can use to make the all-nodes-config IP list network assignments configurable. Ip address lists for all overcloud services which require IPs were added to all-nodes-config so that puppet manifests can be directly supplied the correct network list for each service. Change-Id: I209f2b4f97a4bb78648c54813dad8615770bcf1a
2015-05-21Merge "Overcloud: bump HOT version to 2015-04-30"Jenkins1-1/+1
2015-05-20Overcloud: bump HOT version to 2015-04-30Dan Prince1-1/+1
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
2015-05-20Move sysctl settings into hieradataGiulio Fidente1-4/+0
This will configure the sysctl settings via puppet instead of sysctl image element. Change-Id: Ieb129d4cbe4b6d4184172631499ecd638073564f
2015-05-19Provide RabbitMQ clients with a list of servers instead of VIPGiulio Fidente1-4/+15
This will change the way how RabbitMQ clients get to the servers, they will not go through HAProxy anymore. Change-Id: I522d7520b383a280505e0e7c8fecba9ac02d2c9b
2015-05-13Add Galera as a Pacemaker resource when EnablePacemakerYanis Guenane1-0/+8
This commit aims to support the creation of the galera cluster via Pacemaker. With this commit in, three use-cases will be supported. * Non HA setup / Non Pacemaker setup : The deployment will take place as it is currently the case in f20puppet-nonha. Nothing changes. * Non HA setup / Pacemaker setup : Even though it is a non ha setup, galera cluster via pacemaker will be deployed with a cluster nbr of 1. * HA setup / Non Pacemaker setup : N/A * HA setup / Pacemaker setup : It is assumed that HA setup will always be with pacemaker. So in this situation pacemaker will deploy a cluster of 3 galera master nodes. Depends-On: I7aed9acec11486e0f4f67e4d522727476c767d83 Change-Id: If0c37a86fa8b5aa6d452129bccf7341a3a3ba667
2015-05-05Merge "puppet: install Horizon on overcloud-controller"Jenkins1-0/+4
2015-04-28Add RabbitMQ as a Pacemaker resource when EnablePacemakerGiulio Fidente1-2/+2
Change-Id: I43a74c1db324144d33e96a94cb718db30e0fd243
2015-04-27puppet: install Horizon on overcloud-controllerEmilien Macchi1-0/+4
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-16Add support for Redis configurationYanis Guenane1-0/+4
Add support for Redis configuration on the overcloud controller role. Change-Id: I917ff1e7c0abf9d76b9939a97978e858268deac2 Depends-On: I80a6c284af9eceb6b669a03c5d93256261523331
2015-03-31lb: Allow multiple backendYanis Guenane1-0/+4
Currently tripleo::loadbalancer allow a controller to have only itself as a backend for a service, no matter the number of controller nodes. This patch fixes that using all controller nodes available. Change-Id: Ic8fc022b84850c669b19d37da7f275d9c811e694 Depends-On: I2a46c250bc3325eef9c3128cac2ab45c88b1ae75
2015-03-25Implement mongo_node_ips hiera keyJiri Stransky1-0/+6
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-25Refactor allNodesConfigJiri Stransky1-2/+2
* Create hiera file 'all_nodes' instead of 'rabbit' -- we'll want allNodesConfig to create keys for more services (e.g. mongo_node_ips) and it's not necessary to create a separate hiera file for each. * Rename rabbit_nodes to mongo_node_names -- we'll have more node lists, some services will need hostnames, some services will need IPs, some might need both, so we shouldn't have ambiguity in the hiera key names. Change-Id: If80f9c9b2849ae893e1ab78f1c4d246a2468665c
2015-02-13Split out allNodesConfig SoftwareConfigDan Prince1-0/+60
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