tripleo-heat-templates/overcloud-resource-registry.yaml
Zane Bitter e6603f8b5a Generate the endpoint map statically
A stack is an extremely heavyweight abstraction in Heat. Particularly in
TripleO, every stack includes a copy of all the template and environment
data for all of the stacks in the tree, all of which must be stored anew
in the database.

The EndpointMap abstraction created no fewer than 30 nested stacks, none
of which contained any resources but which existed purely for the
purpose of abstracting out some intrinsic functions used to calculate
the endpoint URLs for the various services. This likely adds several GB
to the memory requirements of the undercloud, and can cause things to
slow to a crawl since all 30 nested stacks need to be queried whenever
we need data from any one of them.

This change eliminates the nested stacks and instead generates the
endpoint map statically. This can be done offline in less than 250ms,
allows the input data to be expressed in an even more human-readable
form, and reduces the runtime overhead of the endpoints map by a factor
of 31, all with no loss of functionality, compatibility or flexibility.

Since we don't run a setup script to generate the tarball, the
endpoint_map.yaml output is checked in to source control. The build
script offers a --check option that can be used to make sure that the
output file is up-to-date with the input data.

Change-Id: I2df8f5569d81c1bde417ff5b12b06b7f1e19c336
(cherry picked from commit 9fb550d3a2)
2016-02-25 11:59:22 -05:00

81 lines
4.4 KiB
YAML

resource_registry:
OS::TripleO::BlockStorage: os-apply-config/cinder-storage.yaml
OS::TripleO::BlockStorage::Net::SoftwareConfig: net-config-noop.yaml
OS::TripleO::Compute: os-apply-config/compute.yaml
OS::TripleO::Compute::Net::SoftwareConfig: net-config-noop.yaml
OS::TripleO::SoftwareDeployment: OS::Heat::StructuredDeployment
OS::TripleO::Controller: os-apply-config/controller.yaml
OS::TripleO::Controller::Net::SoftwareConfig: net-config-noop.yaml
OS::TripleO::ObjectStorage: os-apply-config/swift-storage.yaml
OS::TripleO::ObjectStorage::Net::SoftwareConfig: net-config-noop.yaml
OS::TripleO::CephStorage: os-apply-config/ceph-storage.yaml
OS::TripleO::CephStorage::Net::SoftwareConfig: net-config-noop.yaml
OS::TripleO::ControllerPostDeployment: os-apply-config/controller-post.yaml
OS::TripleO::ComputePostDeployment: os-apply-config/compute-post.yaml
OS::TripleO::ObjectStoragePostDeployment: os-apply-config/swift-storage-post.yaml
OS::TripleO::BlockStoragePostDeployment: os-apply-config/cinder-storage-post.yaml
OS::TripleO::CephStoragePostDeployment: os-apply-config/ceph-storage-post.yaml
OS::TripleO::SwiftDevicesAndProxy::SoftwareConfig: os-apply-config/swift-devices-and-proxy-config.yaml
OS::TripleO::CephClusterConfig::SoftwareConfig: os-apply-config/ceph-cluster-config.yaml
OS::TripleO::AllNodes::SoftwareConfig: os-apply-config/all-nodes-config.yaml
OS::TripleO::BootstrapNode::SoftwareConfig: bootstrap-config.yaml
OS::TripleO::NodeUserData: firstboot/userdata_default.yaml
OS::TripleO::NodeExtraConfigPost: extraconfig/post_deploy/default.yaml
OS::TripleO::Tasks::PackageUpdate: extraconfig/tasks/yum_update.yaml
# "AllNodes" Extra cluster config, runs on all nodes prior to the post_deploy
# phase, e.g when puppet is applied, but after the pre_deploy phase. Useful when
# configuration with knowledge of all nodes in the cluster is required vs single
# node configuration in the pre_deploy step.
OS::TripleO::AllNodesExtraConfig: extraconfig/all_nodes/default.yaml
# TripleO overcloud networks
OS::TripleO::Network: network/networks.yaml
OS::TripleO::VipConfig: os-apply-config/vip-config.yaml
OS::TripleO::Network::External: network/noop.yaml
OS::TripleO::Network::InternalApi: network/noop.yaml
OS::TripleO::Network::StorageMgmt: network/noop.yaml
OS::TripleO::Network::Storage: network/noop.yaml
OS::TripleO::Network::Tenant: network/noop.yaml
OS::TripleO::Network::Ports::NetVipMap: network/ports/net_ip_map.yaml
OS::TripleO::Network::Ports::NetIpMap: network/ports/net_ip_map.yaml
OS::TripleO::Network::Ports::NetIpSubnetMap: network/ports/net_ip_subnet_map.yaml
OS::TripleO::Network::Ports::NetIpListMap: network/ports/net_ip_list_map.yaml
# Port assignments for the controller role
OS::TripleO::Controller::Ports::ExternalPort: network/ports/noop.yaml
OS::TripleO::Controller::Ports::InternalApiPort: network/ports/noop.yaml
OS::TripleO::Controller::Ports::StoragePort: network/ports/noop.yaml
OS::TripleO::Controller::Ports::StorageMgmtPort: network/ports/noop.yaml
OS::TripleO::Controller::Ports::TenantPort: network/ports/noop.yaml
# Port assignments for the compute role
OS::TripleO::Compute::Ports::InternalApiPort: network/ports/noop.yaml
OS::TripleO::Compute::Ports::StoragePort: network/ports/noop.yaml
OS::TripleO::Compute::Ports::TenantPort: network/ports/noop.yaml
# Port assignments for the ceph storage role
OS::TripleO::CephStorage::Ports::StoragePort: network/ports/noop.yaml
OS::TripleO::CephStorage::Ports::StorageMgmtPort: network/ports/noop.yaml
# Port assignments for the swift storage role
OS::TripleO::SwiftStorage::Ports::InternalApiPort: network/ports/noop.yaml
OS::TripleO::SwiftStorage::Ports::StoragePort: network/ports/noop.yaml
OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: network/ports/noop.yaml
# Port assignments for the block storage role
OS::TripleO::BlockStorage::Ports::InternalApiPort: network/ports/noop.yaml
OS::TripleO::BlockStorage::Ports::StoragePort: network/ports/noop.yaml
OS::TripleO::BlockStorage::Ports::StorageMgmtPort: network/ports/noop.yaml
# Port assignments for service virtual IPs for the controller role
OS::TripleO::Controller::Ports::RedisVipPort: network/ports/noop.yaml
# Service Endpoint Mappings
OS::TripleO::EndpointMap: network/endpoints/endpoint_map.yaml
# validation resources
OS::TripleO::AllNodes::Validation: os-apply-config/all-nodes-validation.yaml