2f2d8183e6
When using neutron routed networks we need to specify
either the subnet or a ip address in the fixed-ips-request
when creating neutron ports.
a) For the Vip's:
Adds VipSubnetMap and VipSubnetMapDefaults parameters in
service_net_map.yaml. The two maps are merged, so that the
operator can override the subnet where VIP port should be
hosted. For example:
parameter_defaults:
VipSubnetMap:
ctlplane: ctlplane-leaf1
InternalApi: internal_api_leaf1
Storage: storage_leaf1
redis: internal_api_leaf1
b) For overcloud node ports:
Enrich 'networks' in roles defenition to include both
network and subnet data. Changes the list to a map
instead of a list of strings. New schema:
- name: <role_name>
networks:
<network_name>
subnet: <subnet_name>
For backward compatibility a conditional is used to check
if the data is a map or not. In either case the internal
list of role networks is created as '_role_networks' in
the jinja2 templates.
When the data is a map, and the map contains the 'subnet'
key the subnet specified in roles_data.yaml is used as
the subnet in the fixed-ips-reqest when ports are created.
If subnet is not set (or role.networks is not a map) the
default will be {{network.name_lower}}_subnet.
Also, since the fixed_ips request passed to Vip ports are no
longer [] by default, the conditinal has been updated to
test for 'ip_address' entries in the request.
Partial: blueprint tripleo-routed-networks-templates
Depends-On: I773a38fd903fe287132151a4d178326a46890969
Change-Id: I77edc82723d00bfece6752b5dd2c79137db93443
49 lines
2.0 KiB
YAML
49 lines
2.0 KiB
YAML
---
|
|
features:
|
|
- |
|
|
Composable Networks now support creating L3 routed networks. L3 networks
|
|
use multiple L2 network segments and multiple ip subnets. In addition to
|
|
the base subnet automatically created for any composable network,
|
|
additional subnets can be defined under the ``subnets`` key for each
|
|
network in the data file (``network_data.yaml``) used by composable
|
|
networks. Please refer to the ``network_data_subnets_routed.yaml`` file for
|
|
an example demonstrating how to define composable L3 routed networks.
|
|
- |
|
|
For composable roles it is now possible to control which subnet in a L3
|
|
routed network will host network ports for the role. This is done by
|
|
setting the subnet for each network in the role defenition
|
|
(``roles_data.yaml``). For example::
|
|
|
|
- name: <role_name>
|
|
networks:
|
|
InternalApi:
|
|
subnet: internal_api_leaf2
|
|
Tenant:
|
|
subnet: tenant_leaf2
|
|
Storage:
|
|
subnet: storage_leaf2
|
|
- |
|
|
To enable control of which subnet is used for virtual IPs on L3 routed
|
|
composable networks the new parameter ``VipSubnetMap`` where added. This
|
|
allow the user to override the subnet where the VIP port should be hosted.
|
|
For example::
|
|
|
|
parameter_defaults:
|
|
VipSubnetMap:
|
|
ctlplane: ctlplane-leaf1
|
|
InternalApi: internal_api_leaf1
|
|
Storage: storage_leaf1
|
|
redis: internal_api_leaf1
|
|
upgrade:
|
|
- |
|
|
Deployments using custom names for subnets must also set the subnet to use
|
|
for the roles used in the deployment. I.e if ``NetworkNameSubnetName``
|
|
parameter was used to define a non-default subnet name for any network, the
|
|
role defenition (``roles_data.yaml``) and ``VipSubnetMap`` parameter
|
|
must use the same value.
|
|
|
|
.. Warning:: The update will fail if ``<NetworkName>SubnetName`` was used
|
|
to set a custom subnet name, and the role defenition and/or
|
|
the ``VipSubnetMap`` is not set to match the custom subnet
|
|
name.
|