aboutsummaryrefslogtreecommitdiffstats
path: root/overcloud-resource-registry.yaml
AgeCommit message (Collapse)AuthorFilesLines
2015-03-05Puppet: First support CephEmilien Macchi1-0/+2
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-23BlockStore: Exec puppet after all configurationDan Prince1-0/+1
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/+1
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/+1
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-0/+1
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-0/+1
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-0/+1
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/+1
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-0/+1
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-01-27Compute: consolidated nested stackDan Prince1-1/+0
In I250dc1a8c02626cf7d1a5d2ce92706504ec0c7de we split out just the Controller software config in an effort to provide hooks for alternate implementations (puppet). This sort of worked but caused quirky ordering issues with signal handling. It also causes problems for Tuskar which would prefer to think of these nested stacks and not have us split out just the software configs like this. This patch moves all the compute related stuff for our two implementations: compute.yaml: is used by os-apply-config (uses the tripleo-image-elements) compute-puppet.yaml: uses stackforge puppet-* modules for configuration By duplicating the entire compute in this manner we make it much easier to create dependencies and implement proper signal handling. The only (temporary) downside is the duplication of parameters most of which will eventually go away when we move using the global parameters via Heat environment files instead. Change-Id: I49175d1843520abc80fefe9528442e5dda151f5d
2015-01-27Controller: consolidated nested stackDan Prince1-1/+0
In I228216a0b55ff2d384b281d9ad2a61b93d58dab9 we split out just the Controller software config in an effort to provide hooks for alternate implementations (puppet). This sort of worked but caused quirky ordering issues with signal handling. It also causes problems for Tuskar which would prefer to think of these nested stacks and not have us split out just the software configs like this. This patch moves all the controller related stuff for our two implementations: controller.yaml: is used by os-apply-config (uses the tripleo-image-elements) controller-puppet.yaml: uses stackforge puppet-* modules for configuration By duplicating the entire controller in this manner we make it much easier to create dependencies and implement proper signal handling. The only (temporary) downside is the duplication of parameters most of which will eventually go away when we move towards using the global parameters via Heat environment files instead. Change-Id: Iaf3c889d7c8815f862308cd8e15ce1010059f5c6
2015-01-08Puppet: overcloud controller configDan Prince1-1/+1
This patch provides an alternate implementation of the OS::TripleO::Controller::SoftwareConfig which uses Puppet to drive the configuration. Using this it is possible to create a fully functional overcloud controller instance which has the controller node configured via Puppet stackforge modules. Initially this includes only the following services: MySQL RabbitMQ Keepalived/HAProxy (HA is not yet fully supported however) Nova Neutron Keystone Glance (file backend) Cinder Using these services it is possible to run devtest_overcloud.sh to completion. The idea is that we can quickly add more services once we have CI in place. In order to test this you'll want to build your images with these elements: os-net-config heat-config-puppet puppet-modules hiera None of the OpenStack specific TripleO elements should be used with this approach (the nova/neutron elements were NOT used to build the controller image). Also, rather than use neutron-openvswitch-agent to configure low level networking it is recommended that os-net-config by configured directly via heat modeling rather than parameter passing to init-neutron-ovs. This allows us to configure the physical network while avoiding the coupling to the neutron-openvswitch-element that our standard parameter driven networking currently uses. (We still need to move init-neutron-ovs so that it isn't coupled and/or deprecate its use entirely because the heat drive stuff is more flexible.) Packages may optionally be pre-installed via DIB using the -p option (-p openstack-neutron,openstack-nova) etc. Change-Id: If8462e4eacb08eced61a8b03fd7c3c4257e0b5b8
2015-01-05Controller: Split out software configDan Prince1-0/+1
This is a step towards supporting pluggable software configurations in the heat templates. By moving controller-config out of controller.yaml we make it possible to define alternate implementations by changing the OS::TripleO::ControllerConfig value in the overcloud-resource-registry.yaml heat environment file. Change-Id: I228216a0b55ff2d384b281d9ad2a61b93d58dab9
2014-12-19Compute: drive NW configuration via software confDan Prince1-0/+1
This example extends the compute software configuration so that heat metadata is used to model the os-net-config YAML (ultimately JSON) directly. The existing os-net-config element already supports this format. Configuring the physical network layer in this manner would supplant the ever growing list of Heat parameters that we have and is something that could be automatically generated via tuskar. The default is to use net-config-noop.yaml which will pass no config metadata into the os-net-config element which will essentially disable it in favor of using parameters w/ init-neutron-ovs. Change-Id: I30f325b1751caaef5624537e63ee27c2e418d5c8
2014-11-14Split out Nova software configDan Prince1-0/+2
This is a step towards supporting pluggable software configurations in the heat templates. By moving compute-config out of compute.yaml we make it possible to define alternate implementations by changing the OS::TripleO::Compute::SoftwareConfig value in the overcloud-resource-registry.yaml heat environment file. Co-Authored-By: Steve Hardy <shardy@redhat.com> Change-Id: I250dc1a8c02626cf7d1a5d2ce92706504ec0c7de
2014-10-21Add converted version of block and object storagePeter Belanyi1-0/+2
This patch extends the previous 'Don't use merge.py for overcloud' commit with the cinder-storage.yaml and swift-storage.yaml templates. Requirements for this to deploy: 1. Block and object storage images have to be built (overcloud-cinder-volume and overcloud-swift-storage) 2. The images have to be loaded by devtest_overcloud.sh OVERCLOUD_CINDER_ID=$(load-image -d $TRIPLEO_ROOT/overcloud-cinder-volume.qcow2) OVERCLOUD_SWIFT_ID=$(load-image -d $TRIPLEO_ROOT/overcloud-swift-storage.qcow2) Change-Id: I45f9d9f051970a83e26c0fd924d7c98276958113
2014-10-20Compute and controller templates without merge.pyTomas Sedovic1-0/+3
This provides three templates: overcloud-without-mergepy.yaml, compute.yaml and controller.yaml. These can be used in combination with overcloud-resource-registry.yaml to deploy the overcloud on their own -- without having to do any pre-processing (via merge.py). To test these you have to add the resource registry environment (in addition to the existing `-e` option) and use the new overcloud template in the Heat call in devtest_overcloud.sh (line 374): heat $HEAT_OP -e $TRIPLEO_ROOT/overcloud-env.json \ -e "$TRIPLEO_ROOT/tripleo-heat-templates/overcloud-resource-registry.yaml" \ -t 360 \ -f $TRIPLEO_ROOT/tripleo-heat-templates/overcloud-without-mergepy.yaml \ -P "ExtraConfig=${OVERCLOUD_EXTRA_CONFIG}" \ $STACKNAME The existing overcloud Heat environment ($TRIPLE_ROOT/overcloud-env.json) should keep on working. Scaling is now being controlled by the `ControllerCount` and `ComputeCount` template parameters, though. NOTE: the changes here depend on a fairly recent Heat build (commit e5f285f6cb from ~7th September, 2014). In other words, this requires Juno Heat. Also, passing more than one environment file to Heat requires python-heatclient version 0.2.11. Change-Id: I687a00c7dc164ba044f9f2dfca96a02401427855