summaryrefslogtreecommitdiffstats
path: root/puppet
AgeCommit message (Collapse)AuthorFilesLines
2015-05-27Merge "Map Swift services to isolated networks"Jenkins1-2/+2
2015-05-27Merge "Map Nova services to isolated networks"Jenkins1-2/+2
2015-05-27Merge "Map Heat services to isolated networks"Jenkins1-3/+3
2015-05-27Merge "Map Neutron services to isolated networks"Jenkins1-1/+1
2015-05-27Merge "Map Keystone services to isolated networks"Jenkins1-2/+2
2015-05-27Merge "Map Glance services to isolated networks"Jenkins1-3/+3
2015-05-27Merge "Reuse the various service passwords as db passwords."Jenkins2-14/+31
2015-05-27Merge "Map Cinder services to isolated networks"Jenkins1-2/+2
2015-05-27Merge "Map Ceilometer services to isolated networks"Jenkins1-2/+2
2015-05-27Map Swift services to isolated networksDan Sneddon1-2/+2
This change adds paramters to specify which networks the Swift API services will use. If the storage network exists, it will be used for the Swift API, otherwise the Undercloud 'ctlplane' network will be used. If the storage_mgmt network exists, it will be used for the back-end storage services, otherwise the 'ctlplane' will be used by default. Change-Id: I1d5e966a16416c52935c22efe2d4783cd2192c32
2015-05-27Map Nova services to isolated networksDan Sneddon1-2/+2
This change adds parameters to specify which networks the Nova API and metadata services will use. If the internal_api network exists, it will be used for the bind IP for Nova API and metadata servers, otherwise the Undercloud 'ctlplane' IP will be used by default. Change-Id: Ie420274c7fba80abf9cf2b599431acc47e28fc7a
2015-05-27Map Heat services to isolated networksDan Sneddon1-3/+3
This change adds parameters to specify which networks the Heat services will use. If the internal_api network exists, the Heat API, Heat Cloud Formations, and Heat Cloudwatch services will bind to the IP address on that network, otherwise the services will default to the IP on the Undercloud 'ctlplane' network. Change-Id: I5febe1b9071600b43fa76c6cf415db83cad472ab
2015-05-27Merge "Add Keystone as Pacemaker resource"Jenkins1-2/+7
2015-05-26Map Neutron services to isolated networksDan Sneddon1-1/+1
This change adds parameters to specify which network the Neutron API should use. If the internal_api network exists, Neutron will bind to the IP on that network, otherwise the Undercloud 'ctlplane' network will be used. The network that the Neutron API is bound to can be overridden in an environment file. Change-Id: I11bcebba3a22e8850095250a2ddfaf972339476b
2015-05-26Map Keystone services to isolated networksDan Sneddon1-2/+2
This change adds parameters to specify which networks the Keystone API services will use. If the external network exists, Keystone will bind to the IP on that network for the public API, otherwise it will default to the IP on the Undercloud 'ctlplane' network. If the internal_api network exists it will be used for the Keystone Admin API, otherwise it will default to the 'ctlplane' IP. The networks these APIs are bound to can be overridden in an environment file. Change-Id: I6694ef6ca3b9b7afbde5d4f9d173723b9ce71b20
2015-05-26Map Glance services to isolated networksDan Sneddon1-3/+3
This change adds parameters to specify which networks the Glance services will use. If the internal_api network exists, Glance Registry will bind to the IP on that network, otherwise it will default to the Undercloud 'ctlplane' network. If the storage network exists, Glance API will bind to the IP on that network, otherwise it will default to 'ctlplane'. The networks that these services use can be overridden with an environment file. Change-Id: I6114b2d898c5a0ba4cdb26a3da2dbf669666ba99
2015-05-26Merge "Define Glance Pacemaker resources on $pacemaker_master node only"Jenkins1-24/+23
2015-05-26Map Cinder services to isolated networksDan Sneddon1-2/+2
This change adds parameters to specify which networks the Cinder API and Cinder iSCSI services will listen on. If the internal_api network exists, Cinder API will be bound to the IP on that network, otherwise it will default to the Undercloud 'ctlplane' network. The Cinder iSCSI service will bind to the storage network if it exists, otherwise will also default to using the Undercloud 'ctlplane' network. Change-Id: I98149f108baf28d46eb199b69a72d0f6914486fd
2015-05-26Merge "Ensures mongodb configuration only happens if mongodb is needed"Jenkins1-8/+8
2015-05-26Merge "We don't need to create the clustercheck user anymore"Jenkins1-4/+0
2015-05-26Map Ceilometer services to isolated networksDan Sneddon1-2/+2
This change adds the parameters to specify which networks the Ceilometer and MongoDB servers listen on. It is set to the internal_api network if present, and reverts to the default Undercloud 'ctlplane' network if not. Change-Id: Ib646e4a34496966f9b1d454f04d07bf95543517f
2015-05-26Switch net-config templates to use OS::stack_idDan Prince5-5/+5
This patch removes the custom config_id outputs and replaces it with OS::stack_id which allows us to just call get_resource in the parent stack. The motivation for this change is we'll be adding more os-net-config templates and it would be nice to take advantage of this newer template feature. Change-Id: I6fcb26024b94420779b86766e16d8a24210c4f8e
2015-05-26Update neutron local_ip to use the tenant networkDan Prince2-2/+29
This patch uses the new NetIpMap and ServiceMap abstractions to assign the Neutron tenant tunneling network addresses. By default this is associated with the tenant network. If no tenant network is activated this will still default to the control plane IP address. Change-Id: I9db7dd0c282af4e5f24947f31da2b89f231e6ae4
2015-05-26Add isolated network ports to block storage rolesDan Prince1-0/+28
This patch updates the cinder block storage roles so that they can optionally make use of isolated network ports on the storage, storage management, and internal_api networks. -Multiple networks are created based upon settings in the heat resource registry. These nets will either use the noop network (the control plane pass-thru default) or create a custom Neutron port on each of the configured networks. -The ipaddress/subnet of each network is passed passed into the NetworkConfig resource which drives os-net-config. This allows the deployer to define a custom network template for static IPs, etc on each of the networks. -The ipaddress is exposed as an output parameter. By exposing the individual addresses as outputs we allow Heat to construct collections of ports for various services. Change-Id: I4e18cd4763455f815a8f8b82c93a598c99cc3842
2015-05-26Add isolated network ports to swift rolesDan Prince1-0/+28
This patch updates the swift roles so that they can optionally make use of isolated network ports on the storage, storage management, and internal API networks. -Multiple networks are created based upon settings in the heat resource registry. These nets will either use the noop network (the control plane pass-thru default) or create a custom Neutron port on each of the configured networks. -The ipaddress/subnet of each network is passed passed into the NetworkConfig resource which drives os-net-config. This allows the deployer to define a custom network template for static IPs, etc on each of the networks. -The ipaddress is exposed as an output parameter. By exposing the individual addresses as outputs we allow Heat to construct collections of ports for various services. Change-Id: I9984404331705f6ce569fb54a38b2838a8142faa
2015-05-26Add isolated network ports to ceph rolesDan Prince1-0/+19
This patch updates the ceph roles so that they can optionally make use of isolated network ports on the storage and storage management networks. -Multiple networks are created based upon settings in the heat resource registry. These nets will either use the noop network (the control plane pass-thru default) or create a custom Neutron port on each of the configured networks. -The ipaddress/subnet of each network is passed passed into the NetworkConfig resource which drives os-net-config. This allows the deployer to define a custom network template for static IPs, etc on each of the networks. -The ipaddress is exposed as an output parameter. By exposing the individual addresses as outputs we allow Heat to construct collections of ports for various services. Change-Id: I35cb8e7812202f8a7bc0379067bf33d483cd2aec
2015-05-26Add isolated network ports to compute rolesDan Prince1-0/+28
This patch updates the compute roles so that they can optionally make use of isolated network ports on the tenant, storage, and internal_api networks. -Multiple networks are created based upon settings in the heat resource registry. These nets will either use the noop network (the control plane pass-thru default) or create a custom Neutron port on each of the configured networks. -The ipaddress/subnet of each network is passed passed into the NetworkConfig resource which drives os-net-config. This allows the deployer to define a custom network template for static IPs, etc on each of the networks. -The ipaddress is exposed as an output parameter. By exposing the individual addresses as outputs we allow Heat to construct collections of ports for various services. Change-Id: Ib07b4b7256ede7fb47ecc4eb5abe64b9144b9aa1
2015-05-26Add isolated network ports to controller rolesDan Prince1-0/+46
This patch updates the controller roles so that they can optionally make use of isolated network ports on each of 5 available overcloud networks. -Multiple networks are created based upon settings in the heat resource registry. These nets will either use the noop network (the control plane pass-thru default) or create a custom Neutron port on each of the configured networks. -The ipaddress/subnet of each network is passed passed into the NetworkConfig resource which drives os-net-config. This allows the deployer to define a custom network template for static IPs, etc on each of the networks. -The ipaddress is exposed as an output parameter. By exposing the individual addresses as outputs we allow Heat to construct collections of ports for various services. Change-Id: I9bbd6c8f5b9697ab605bcdb5f84280bed74a8d66
2015-05-22Define Glance Pacemaker resources on $pacemaker_master node onlyGiulio Fidente1-24/+23
Previously the Glance Pacemaker resources were mistakenly defined on all nodes causing intermittent duplication errors. Change-Id: I839ee49b153aa96ec08ebdb7e44aaeac28785963
2015-05-22Add Keystone as Pacemaker resourceJay Dobies1-2/+7
Change-Id: I4631f962415164975143e94ec0b251ee5972c552
2015-05-22Merge "Add Glance as Pacemaker resource"Jenkins2-5/+30
2015-05-22Merge "Add Cinder services as Pacemaker resources"Jenkins1-7/+51
2015-05-21Align puppet Controller post-deploy Deployment namesSteven Hardy1-11/+11
Align all Deployment resource so we can use a glob convention for stepped deployments via heat hooks/breakpoints. Since most resources already use a FooDeployment_StepN convention, align those which deviate from this as a precursor to supporting stepped deployment, e.g stepping through "*Deployment_Step*". Change-Id: I6bfee04649aa36116d1141ebe06d08b310ec8939
2015-05-21Merge "Overcloud: bump HOT version to 2015-04-30"Jenkins16-16/+16
2015-05-21Add Glance as Pacemaker resourceGiulio Fidente2-5/+30
Change-Id: If87cc4d55e8524246d2cd41a62805f84780006b2
2015-05-21Add Cinder services as Pacemaker resourcesJiri Stransky1-7/+51
Add Pacemaker resources for Cinder services, also add relevant ordering and colocation constraints. Change-Id: Idc2e1b5ec96d882543f7a1a4ec723a010020ab02
2015-05-21Merge "Start non-pacemakerized services in step 4"Jenkins1-4/+1
2015-05-21We don't need to create the clustercheck user anymoreGiulio Fidente1-4/+0
With change I4b6b77e878017bf92d7c59c868d393e74405a355 we started using the root user for clustercheck script so we don't need to create the clustercheck user anymore. Change-Id: Ic92bd12baeeeaf3f674e766fbc0a8badfb44822f
2015-05-21Merge "Use clustercheck script to control galera-ready"Jenkins2-17/+9
2015-05-21Start non-pacemakerized services in step 4Jiri Stransky1-4/+1
Previously we've been starting non-pacemakerized services in step 3 on bootstrap node and in step 4 on others. Now that $sync_db in OpenStack Puppet modules is decoupled from $enabled and $manage_service [1] we can start the services in step 4 on all nodes. [1] https://bugs.launchpad.net/puppet-glance/+bug/1452278 Change-Id: I6351d972ab00f4661d98338d95310d33f271de2f
2015-05-21Merge "Prepare for adding OpenStack services to Pacemaker"Jenkins1-24/+124
2015-05-20Overcloud: bump HOT version to 2015-04-30Dan Prince16-16/+16
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-20Merge "Move sysctl settings into hieradata"Jenkins8-4/+20
2015-05-20Merge "Set up corosync using hostnames rather than IPs"Jenkins1-1/+1
2015-05-20Move sysctl settings into hieradataGiulio Fidente8-4/+20
This will configure the sysctl settings via puppet instead of sysctl image element. Change-Id: Ieb129d4cbe4b6d4184172631499ecd638073564f
2015-05-20Use clustercheck script to control galera-readyGiulio Fidente2-17/+9
The exec timeout/attempts is configured so that it is left running for up to 30mins if the command runs but is unsuccessfull and up to 2h if the command times out. Change-Id: I4b6b77e878017bf92d7c59c868d393e74405a355
2015-05-20Ensures mongodb configuration only happens if mongodb is neededGiulio Fidente1-8/+8
Change-Id: I7e9eb665275bd48d9c079934cc01ba62b5f59e16
2015-05-20Prepare for adding OpenStack services to PacemakerJiri Stransky1-24/+124
We need to write config for OpenStack services on all nodes in step 3 so that we can then create pacemaker resources in step 4. (If we wrote config on non-bootstrap nodes in step 4 as it is currently, services on those nodes might be started unconfigured. This is an inter-node ordering issue that cannot be easily solved from within Puppet manifests, hence the use of steps to enforce this ordering.) Change-Id: Ia78ec38520bd1295872ea2690e8d3f8d6b01c46c
2015-05-19Clone params for pacemaker rabbitmq resourceJiri Stransky1-1/+1
Set clone params according to [1]. [1] https://github.com/beekhof/osp-ha-deploy/blob/f8a65ab4c34f94737edde7db60337b830bfe6311/pcmk/rabbitmq.scenario Change-Id: I5644de2d6253ab762a1420560ecb5bee2fd83092 Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
2015-05-19Provide RabbitMQ clients with a list of servers instead of VIPGiulio Fidente6-30/+18
This will change the way how RabbitMQ clients get to the servers, they will not go through HAProxy anymore. Change-Id: I522d7520b383a280505e0e7c8fecba9ac02d2c9b