summaryrefslogtreecommitdiffstats
path: root/overcloud-resource-registry-puppet.yaml
AgeCommit message (Collapse)AuthorFilesLines
2015-03-06Correct the parameter_defaults section name.Dan Prince1-3/+2
Also, we can actually uncomment this now that heatclient 0.3 has been released. Change-Id: I0b4ce13f1426c364ea7921596022e5165e025fdb
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-12Move all puppet templates into puppet directory.Dan Prince1-5/+5
This cleans up the top level tree by moving all the puppet related bits into the puppet directory. The only exception is overcloud-resource-registry-puppet.yaml which is the puppet environment file and is used externally. Change-Id: Idb65a7143b0f29e5579d4e9d1642e4cda6f65d50
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-02-05puppet: Add EnablePackageInstall optionDan Prince1-0/+4
This adds an option which enables package installation via Yum when Puppet executes. Users might want to disable Yum installation of packages via puppet when using pre-installed images. The option is off by default: meaning that Puppet will no longer install packages by default. Users will need to enable the EnablePackageInstall in order to get the previous behavior. The intent is to use the default_parameters section of the Heat environment to allow users to cleanly enable this features without wiring it into the top level. This is because the new parameter is Puppet specific and doesn't really apply to other implementations. Kilo Heat already has support for default_parameters and so does python-heatclient. NOTE: most TripleO users do not yet have the heatclient features because setup-clienttools in tripleo-incubator only installs releases via pip. It is for these reasons the default_parameters section in overcloud-resource-registry-puppet.yaml is commented out for now. Change-Id: I3af71b801b87d080b367d9e4a1fb44c1bfea6e87
2015-01-27Puppet: Cinder common block storage supportDan Prince1-1/+1
This patch implements the required changes to configure common Cinder block storage nodes via Puppet. Change-Id: Iac8b4679a00f58d5faac4a1d08b7a830f0360ba5
2015-01-27Puppet: Swift Storage node supportDan Prince1-1/+1
This patch implements the required changes to configure swift storage nodes via Puppet. Similar to the overcloud we generate the rings on each node (with the same seed). Change-Id: I677c85b09b6e656b3ac1f938a4bd6bc7daae1755
2015-01-27Compute: consolidated nested stackDan Prince1-2/+1
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-2/+1
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-0/+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-05Puppet: overcloud compute configDan Prince1-0/+8
This patch provides an alternate implementation of the OS::TripleO::Compute::SoftwareConfig which uses Puppet to drive the configuration. Using this it is possible to create a fully functional overcloud compute instance which has the compute node configured via Puppet stackforge modules. This includes all the Nova, Neutron, and Ceilometer configuration required to make things work. 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/ceilometer elements were NOT used to build the compute 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). Change-Id: Ic36be25d70f0a94ca07ffda6e0005669b81c1ac7