aboutsummaryrefslogtreecommitdiffstats
path: root/overcloud-resource-registry.yaml
AgeCommit message (Collapse)AuthorFilesLines
2015-11-11Refacter Endpoints into EndpointMapMark Chappell1-0/+4
Because many of the service endpoints URLs use the same patterns for generating the URLs it makes sense to use the same templates to reduce the copy and paste. In the process also adds support for explicitly specifying hostnames for use in the endpoints. Note: DNS must be pre-configured. The Heat templates do not directly configure DNS. Change-Id: Ie3270909beca3d63f2d7e4bcb04c559380ddc54d Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
2015-10-02Move os-apply-config templates into a directoryDan Prince1-15/+15
This patch moves all of the os-apply-config (tripleo-image-elements) specific templates into a common directory. This matches what we do for puppet and should help new users more easily understand the project layout. Change-Id: I7dce2a770d56795f3ea22c8a464595c4a0c60832
2015-09-17Add "AllNodes" ExtraConfig interfaceSteven Hardy1-0/+6
Adds hook to enable additional "AllNodes" config to be performed prior to applying puppet - this is useful when you need to build configuration data which requires knowledge of all nodes in a cluster, or of the entire deployment. As an example, there is a sample config template which collects the hostname and mac addresses for all nodes in the deployment then writes the data to all Controller nodes. Something similar to this may be required to enable creation of the nexus_config in https://review.openstack.org/#/c/198754/ There's also another, simpler, example which shows how you could share the output of an OS::Heat::RandomString between nodes. Change-Id: I8342a238f50142d8c7426f2b96f4ef1635775509
2015-09-17Merge "network validation to ping test each interface"Jenkins1-0/+3
2015-09-05Allow 'ctlplane' to be used within Net IP MapsDan Prince1-0/+1
When using network isolation you might want to selective move one of the services back to the default ctlplane network by simply using the ServiceNetMap parameter. This patch adds ctlplane to the output parameters for both the net_ip_map and net_ip_list_map nested stacks so that this is possible. As part of this patch we also split out the NetIpSubnetMap into its own unique nested stack so that the Heat input parameters for this stack are more clearly named. Change-Id: Iaa2dcaebeac896404e87ec0c635688b2a59a9e0f
2015-07-24network validation to ping test each interfaceDan Prince1-0/+3
This patches wires in a new "all nodes" validation resource that can be used to add validations that occur early on during the deployment process. This occurs after the nodes have been brought online and the initial networks have been configured but before any "post" (puppet, etc.) sort of configuration has been executed. A initial validation script has been added to ping test network IPs on each network. When using network isolation this will ensure network connectivity (vlans, etc) are working on each node and if not the heat stack will fail early, allowing time to fix the network connections and retry the stack creation via an update. Change-Id: I63cf95b27e8ad2aed48718cf84df5f324780e597 Co-Authored-By: Ian Main <imain@redhat.com> Co-Authored-By: Ryan Hallisey <rhallise@redhat.com>
2015-06-13Remove Redis VirtualIP from params and build it from Neutron::PortGiulio Fidente1-0/+3
The redis_vip should come from a Neutron Port as its cidr depends on the Neutron Network configuration. This change adds 2 new files and modifies 1 in the network/ports directory: - noop.yaml - Passes through the ctlplane Controller IP (modified) - ctlplane_vip.yaml - Creates a new VIP on the control plane - vip.yaml - Creates a VIP on the named network (for isolated nets) Also, changes to overcloud-without-mergepy.yaml create the Redis Virtual IP. The standard resource registry was modified to use noop.yaml for the new Redis VIP. The Puppet resource registry was modified to use ctlplane_vip.yaml by default, but can be made to use vip.yaml when network isolation is used by using an environment file. vip.yaml will place the VIP according to the ServiceNetMap, which can also be overridden. We use this new VIP port definition to assign a VIP to Redis, but follow-up patches will assign VIPs to the rest of the services in a similar fashion. Co-Authored-By: Dan Sneddon <dsneddon@redhat.com> Change-Id: I2cb44ea7a057c4064d0e1999702623618ee3390c
2015-06-08Config & deployments to update overcloud packagesSteve Baker1-0/+1
This change adds config and deployment resources to trigger package updates on nodes. The deployments are triggered by doing a stack-update and setting one of the parameters to a unique value. The intent is that rolling update will be controlled by setting breakpoints on all of the UpdateDeployment resources inside the role resource groups. Change-Id: I56bbf944ecd6cbdbf116021b8a53f9f9111c134f
2015-06-03Add virtual IPs for split out networksDan Prince1-0/+1
This patch adds VIPs for the internal_api, storage, and storage management networks. For puppet these are persisted into a local vip-config hieradata file which is then used by puppet-tripleo's loadbalancer module to apply per-service VIP settings. Change-Id: I909c3bdc9d17a8e15351f4797287769e3f76c849
2015-06-03Make all-nodes Ip networks configurableDan Prince1-0/+1
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-26Add a network ports IP mapping resourceDan Prince1-0/+2
This patch adds a resource which constructs a Json output parameter called net_ip_map which will allow us to easily extract arbitrary IP addresses for each network using the get_attr function in heat. The goal is to use this data construct in each role template to obtain the correct IP address on each network. Change-Id: I1a8c382651f8096f606ad38f78bbd76314fbae5f
2015-05-26Add isolated network ports to block storage rolesDan Prince1-0/+5
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/+5
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/+4
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/+5
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/+7
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-22Wire in optional network creation for overcloudDan Prince1-0/+9
This patch enables uses to selectively enable the creation of split out networks for the overcloud traffic. These networks will be created on the undercloud's neutron instance. By default a noop network is used so that no extra networks are created. This allows our default to continue being all traffic on the control plane. Change-Id: Ied49d9458c2d94e9d8e7d760d5b2d971c7c7ed2d
2015-04-29Merge "Add hooks for extra post-deployment config"Jenkins1-0/+1
2015-04-24Separate the network configuration per flavor.Dan Sneddon1-1/+5
This change allows a different network config for each family of hosts. For instance, the controller may have a different network configuration than a block storage node. This change adds a declaration for each family in the overcloud-resource-registry.yaml & overcloud-resource-registry-puppet.yaml. Change-Id: I083df7ebbb535f97d8ddec2ac0e06281c55986cd
2015-04-24Add hooks for extra post-deployment configSteven Hardy1-0/+1
Adds optional hooks which can run operator defined additional config on nodes after the application deployment has completed. Change-Id: I3f99e648efad82ce2cd51e2d5168c716f0cee8fe
2015-04-24Enable passing optional first-boot user-dataSteven Hardy1-0/+1
Currently all the OS::Nova::Server resource created don't pass any user-data. It's possible to pass user-data as well as using heat SoftwareConfig/SoftwareDeployment resources, and this can be useful when you have simple "first boot" tasks which are possible either via cloud-init, or via simple run-once scripts. This enables passing such data by implementing a new provider resource OS::TripleO::NodeUserData, which defaults to passing an empty mime archive (thus it's a no-op). An example of non no-op usage is also provided. Change-Id: Id0caba69768630e3a10439ba1fc2547a609c0cfe
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