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: I77edc82723d00bfece6752b5dd2c79137db93443
changes/01/582301/44
Harald Jensås
4 years ago
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. |
||||