Dynamically generate VIP hiera entries

These were hardcoded, even though the rest of the network-related bits
were dynamically generated with jinja.

This will end up creating the same entries as before, skipping the VIP
for the Tenant network and the Management network (which is not included
in the default roles). Also, the external network will now have an extra
hiera entry called external_virtual_ip, besides the public_virtual_ip.
They will have the same value, however, external_virtual_ip is
automatically generated as opposed to the public_virtual_ip. Hopefully
we can remove the instance of public_virtual_ip at some point and rely
on the automatically generated entries only.

Change-Id: I7f5285e2936b2158a4a8a5edc97a6a09f891fb1a
Related-Bug: #1732457
This commit is contained in:
Juan Antonio Osorio Robles
2017-11-16 09:28:39 +02:00
parent 3b1e644e8e
commit 365230af46

View File

@@ -183,9 +183,9 @@ resources:
get_param: [NetVipMap, {get_param: [ServiceNetMap, keystone_public_api_network]}]
public_virtual_ip: {get_param: [NetVipMap, {get_param: ExternalNetName}]}
controller_virtual_ip: {get_param: [NetVipMap, ctlplane]}
internal_api_virtual_ip: {get_param: [NetVipMap, {get_param: InternalApiNetName}]}
storage_virtual_ip: {get_param: [NetVipMap, {get_param: StorageNetName}]}
storage_mgmt_virtual_ip: {get_param: [NetVipMap, {get_param: StorageMgmtNetName}]}
{%- for network in networks if network.vip|default(false) %}
{{network.name_lower}}_virtual_ip: {get_param: [NetVipMap, {get_param: {{network.name}}NetName}]}
{%- endfor %}
redis_vip: {get_param: RedisVirtualIP}
# public_virtual_ip and controller_virtual_ip are needed in
# both HAproxy & keepalived.