path: root/overcloud-resource-registry-puppet.yaml
diff options
authorSteven Hardy <shardy@redhat.com>2016-07-04 16:28:41 +0100
committerSteven Hardy <shardy@redhat.com>2016-07-05 10:58:31 +0100
commitb345dbea16ad3edd600c62848d8ee116f4df16ee (patch)
tree26e0820820da66b88b5380c408f3ed7ab38f1f9c /overcloud-resource-registry-puppet.yaml
parent519b94ff1e2b4d3de563ca28c14cb48a4fbcf34c (diff)
Combine BootstrapNodeDeployment with AllNodesDeployment
Currently we have a special controller-only deployment which writes the name/ip of the "bootstrap node", e.g the cluster master, which defaults to the first node in the Controller ResourceGroup. Now we're moving to fully composable services/roles, it's possible folks will want to deploy services that expect to detect the bootstrap node (e.g so only one node does a DB sync) for non-controller roles. So, take this opportunity to combine the bootstrap node deployment with the "all nodes" data, such that we deploy the same data for all roles. Because the boostrap node data is per role cluster, rather than truly global, we pass it via input_values into each per-role Deployment. At some future point we might consider renaming this, e.g to something which describes per-cluster config vs "all nodes", but as a first step let's just rationalize the resources. Change-Id: I4011526a13c51b3d0f95c17fe8ed38115b4fdce4
Diffstat (limited to 'overcloud-resource-registry-puppet.yaml')
1 files changed, 0 insertions, 1 deletions
diff --git a/overcloud-resource-registry-puppet.yaml b/overcloud-resource-registry-puppet.yaml
index 1ef3660..3e3e2a0 100644
--- a/overcloud-resource-registry-puppet.yaml
+++ b/overcloud-resource-registry-puppet.yaml
@@ -20,7 +20,6 @@ resource_registry:
OS::TripleO::SwiftDevicesAndProxy::SoftwareConfig: puppet/swift-devices-and-proxy-config.yaml
OS::TripleO::CephClusterConfig::SoftwareConfig: puppet/ceph-cluster-config.yaml
OS::TripleO::AllNodes::SoftwareConfig: puppet/all-nodes-config.yaml
- OS::TripleO::BootstrapNode::SoftwareConfig: puppet/bootstrap-config.yaml
# Tasks (for internal TripleO usage)
OS::TripleO::Tasks::UpdateWorkflow: OS::Heat::None