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
3 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. |
|||