diff options
author | Zane Bitter <zbitter@redhat.com> | 2017-07-11 15:52:37 -0400 |
---|---|---|
committer | Zane Bitter <zbitter@redhat.com> | 2017-07-11 15:52:37 -0400 |
commit | b5c110f1c18dd006bae15c48d4936ec8ad307e32 (patch) | |
tree | 7b1cd94f83c7b8ffce3e111e15c5bd3a77e9b99b | |
parent | 322f2dbd4c1d9c8617186bcb9211d7a1fe10ba3f (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.yaml | 9 |
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: | |