Browse Source
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: I77edc82723d00bfece6752b5dd2c79137db93443changes/01/582301/44
59 changed files with 559 additions and 201 deletions
@ -0,0 +1,48 @@
|
||||
--- |
||||
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. |