aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorZane Bitter <zbitter@redhat.com>2017-07-11 15:52:37 -0400
committerZane Bitter <zbitter@redhat.com>2017-07-11 15:52:37 -0400
commitb5c110f1c18dd006bae15c48d4936ec8ad307e32 (patch)
tree7b1cd94f83c7b8ffce3e111e15c5bd3a77e9b99b
parent322f2dbd4c1d9c8617186bcb9211d7a1fe10ba3f (diff)
Add dependency relationship between nested get_attr targets
Starting with Pike, Heat will do attribute resolution in a single pass. A consequence of this is that when the result of a get_attr is passed to another get_attr call, there must be a dependency relationship between the resources so that the inner attribute is resolved first before we try to determine which attributes are required from the resource in the outer call. There are two uses of nested dep_attr in the overcloud template. One (which hopefully can be removed soon) is in the allNodesConfig resource. In this case, the {{primary_role_name}}IpListMap already depends on the ServiceNetMap. The second is in the KeystoneAdminVip output. This patch makes the VipMap depend on the ServiceNetMap so that attributes can be resolved in a single pass in that case. Change-Id: I438a79748b9b408ec1101271d96c60d84028b57e
-rw-r--r--overcloud.j2.yaml9
1 files changed, 9 insertions, 0 deletions
diff --git a/overcloud.j2.yaml b/overcloud.j2.yaml
index 56a10a52..f238e3b4 100644
--- a/overcloud.j2.yaml
+++ b/overcloud.j2.yaml
@@ -680,6 +680,10 @@ resources:
StorageMgmtIp: {get_attr: [StorageMgmtVirtualIP, ip_address]}
StorageMgmtIpUri: {get_attr: [StorageMgmtVirtualIP, ip_address_uri]}
# No tenant or management VIP required
+ # Because of nested get_attr functions in the KeystoneAdminVip output, we
+ # can't determine which attributes of VipMap are used until after
+ # ServiceNetMap's attribute values are available.
+ depends_on: ServiceNetMap
# All Nodes Validations
AllNodesValidationConfig:
@@ -787,6 +791,11 @@ outputs:
value: {get_attr: [EndpointMapData, value, KeystonePublic, uri]}
KeystoneAdminVip:
description: Keystone Admin VIP endpoint
+ # Note that these nested get_attr functions require a dependency
+ # relationship between VipMap and ServiceNetMap, since we can't determine
+ # which attributes of VipMap are used until after ServiceNetMap's attribute
+ # values are available. If this is ever reworked to not use nested
+ # get_attr, that dependency can be removed.
value: {get_attr: [VipMap, net_ip_map, {get_attr: [ServiceNetMap, service_net_map, KeystoneAdminApiNetwork]}]}
EndpointMap:
description: |