150 lines
7.6 KiB
YAML
Raw Normal View History

# List of networks, used for j2 templating of enabled networks
#
# Supported values:
#
# name: Name of the network (mandatory)
# name_lower: lowercase version of name used for filenames
# (optional, defaults to name.lower())
# service_net_map_replace: if name_lower is set to a custom name this should be set
# to original default (optional). This field is only necessary when
# changing the default network names, not when adding a new custom network.
# enabled: Is the network enabled (optional, defaults to true)
# external_resource_network_id: Optional. If set, it should be the UUID of an existing already
# created Neutron network that will be used in place of creating a
# new network.
# external_resource_vip_id: Optional. If set, it should be the UUID of an existing already
# created Neutron port for the VIP that will be used
# in place of creating a new port.
# external_resource_subnet_id: Optional. If set, it should be the UUID of an existing already
# created Neutron subnet that will be used in place of creating a
# new subnet for the network.
# external_resource_segment_id: Optional. If set, it should be the UUID of an existing already
# created Neutron segment that will be used in place of creating a
# new segment for the network.
# NOTE: False will use noop.yaml for unused legacy networks to support upgrades.
# vlan: vlan for the network (optional)
# vip: Enable creation of a virtual IP on this network
Remove ipv6 specific network templates This change renders the IPv6 versions of the isolated networks using j2. To allow for backward compatibility, there will be 2 versions of the network definitions, <network>.yaml and <network>_v6.yaml. If the ip_subnet contains an IPv6 address, or if ipv6: true is set on the network definition in network_data.yaml, then the <network>.yaml version will contain an IPv6 definition, otherwise the <network>.yaml will be IPv4, and the <network>_v6.yaml will be IPv6. In a future follow-up patch, we will probably only create the required versions of the networks, either IPv4, IPv6, not both. The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway settings in the network_data.yaml definition file are used for the <network>_v6.yaml network definition. Note that these subnet/cidr/gateway definitions only set the defaults, which can be overridden with parameters set in an environment file. Since the parameters for IP and subnet range are the same (e.g. InternalApiNetCidr applies to both IPv4/v6), only one version can be used at a time. If an operator wishes to use dual-stack IPv4/IPv6, then two different networks should be created, and both networks can be applied to a single interface. Note that the workflow for the operator is the same as before this change, but a new example template has been added to environments/network-environment-v6.yaml. Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc Partially-Implements: blueprint composable-networks Closes-bug: 1714115
2017-08-30 11:26:52 -07:00
# ip_subnet: IP/CIDR, e.g. '192.168.24.0/24' or '2001:db8:fd00:1000::/64'
# (optional, may use parameter defaults instead)
# allocation_pools: IP range list e.g. [{'start':'10.0.0.4', 'end':'10.0.0.250'}]
# gateway_ip: gateway for the network (optional, may use parameter defaults)
# routes: Optional, list of networks that should be routed via network gateway.
# Example: [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
# A single /16 supernet route could be used for 255 smaller /24 subnets.
Remove ipv6 specific network templates This change renders the IPv6 versions of the isolated networks using j2. To allow for backward compatibility, there will be 2 versions of the network definitions, <network>.yaml and <network>_v6.yaml. If the ip_subnet contains an IPv6 address, or if ipv6: true is set on the network definition in network_data.yaml, then the <network>.yaml version will contain an IPv6 definition, otherwise the <network>.yaml will be IPv4, and the <network>_v6.yaml will be IPv6. In a future follow-up patch, we will probably only create the required versions of the networks, either IPv4, IPv6, not both. The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway settings in the network_data.yaml definition file are used for the <network>_v6.yaml network definition. Note that these subnet/cidr/gateway definitions only set the defaults, which can be overridden with parameters set in an environment file. Since the parameters for IP and subnet range are the same (e.g. InternalApiNetCidr applies to both IPv4/v6), only one version can be used at a time. If an operator wishes to use dual-stack IPv4/IPv6, then two different networks should be created, and both networks can be applied to a single interface. Note that the workflow for the operator is the same as before this change, but a new example template has been added to environments/network-environment-v6.yaml. Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc Partially-Implements: blueprint composable-networks Closes-bug: 1714115
2017-08-30 11:26:52 -07:00
# ipv6_subnet: Optional, sets default IPv6 subnet if IPv4 is already defined.
# ipv6_allocation_pools: Set default IPv6 allocation pools if IPv4 allocation pools
# are already defined.
# gateway_ipv6: Set an IPv6 gateway if IPv4 gateway already defined.
# routes_ipv6: Optional, list of networks that should be routed via network gateway.
# Example: [{'destination':'fd00:fd00:fd00:3004::/64',
# 'nexthop':'fd00:fd00:fd00:3000::1'}]
Remove ipv6 specific network templates This change renders the IPv6 versions of the isolated networks using j2. To allow for backward compatibility, there will be 2 versions of the network definitions, <network>.yaml and <network>_v6.yaml. If the ip_subnet contains an IPv6 address, or if ipv6: true is set on the network definition in network_data.yaml, then the <network>.yaml version will contain an IPv6 definition, otherwise the <network>.yaml will be IPv4, and the <network>_v6.yaml will be IPv6. In a future follow-up patch, we will probably only create the required versions of the networks, either IPv4, IPv6, not both. The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway settings in the network_data.yaml definition file are used for the <network>_v6.yaml network definition. Note that these subnet/cidr/gateway definitions only set the defaults, which can be overridden with parameters set in an environment file. Since the parameters for IP and subnet range are the same (e.g. InternalApiNetCidr applies to both IPv4/v6), only one version can be used at a time. If an operator wishes to use dual-stack IPv4/IPv6, then two different networks should be created, and both networks can be applied to a single interface. Note that the workflow for the operator is the same as before this change, but a new example template has been added to environments/network-environment-v6.yaml. Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc Partially-Implements: blueprint composable-networks Closes-bug: 1714115
2017-08-30 11:26:52 -07:00
# ipv6: If ip_subnet not defined, this specifies that the network is IPv6-only.
# NOTE: IP-related values set parameter defaults in templates, may be overridden,
# either by operators, or e.g in environments/network-isolation-v6.yaml where we
# set some default IPv6 addresses.
# compat_name: for existing stack you may need to override the default
# transformation for the resource's name.
# mtu: Set the maximum transmission unit (MTU) that is guaranteed to pass
# through the data path of the segments in the network.
# (optional, defaults to 1500)
# subnets: A map of additional subnets for the network (optional). The map
# takes the following format:
# {'<subnet name>': {'enabled': '<true|false>',
# 'vlan': '<vlan-id>',
# 'ip_subnet': '<IP/CIDR>',
# 'allocation_pools': '<IP range list>',
# 'gateway_ip': '<gateway IP>',
# 'routes': '<Routes list>',
# 'ipv6_subnet': '<IPv6/CIDR>',
# 'ipv6_allocation_pools': '<IPv6 range list>',
# 'gateway_ipv6': '<IPv6 gateway>',
# 'routes_ipv6': '<Routes list>',
# 'external_resource_subnet_id': '<Existing subnet UUID (optional)>'}}
# 'external_resource_segment_id': '<Existing segment UUID (optional)>'}}
#
# Example:
# - name Example
# vip: false
# ip_subnet: '10.0.2.0/24'
# allocation_pools: [{'start': '10.0.2.4', 'end': '10.0.2.250'}]
# gateway_ip: '10.0.2.254'
#
# To support backward compatibility, two versions of the network definitions
# will be created, network/<network>.yaml and network/<network>_v6.yaml. Only
Remove ipv6 specific network templates This change renders the IPv6 versions of the isolated networks using j2. To allow for backward compatibility, there will be 2 versions of the network definitions, <network>.yaml and <network>_v6.yaml. If the ip_subnet contains an IPv6 address, or if ipv6: true is set on the network definition in network_data.yaml, then the <network>.yaml version will contain an IPv6 definition, otherwise the <network>.yaml will be IPv4, and the <network>_v6.yaml will be IPv6. In a future follow-up patch, we will probably only create the required versions of the networks, either IPv4, IPv6, not both. The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway settings in the network_data.yaml definition file are used for the <network>_v6.yaml network definition. Note that these subnet/cidr/gateway definitions only set the defaults, which can be overridden with parameters set in an environment file. Since the parameters for IP and subnet range are the same (e.g. InternalApiNetCidr applies to both IPv4/v6), only one version can be used at a time. If an operator wishes to use dual-stack IPv4/IPv6, then two different networks should be created, and both networks can be applied to a single interface. Note that the workflow for the operator is the same as before this change, but a new example template has been added to environments/network-environment-v6.yaml. Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc Partially-Implements: blueprint composable-networks Closes-bug: 1714115
2017-08-30 11:26:52 -07:00
# one of these files may be used in the deployment at a time, since the
# parameters used for configuration are the same in both files. In the
# future, this behavior may be changed to create only one file for custom
# networks. You may specify IPv6 addresses for ip_subnet, allocation_pools,
# and gateway_ip if no IPv4 addresses are used for a custom network, or set
# ipv6: true, and the network/<network>.yaml file will be configured as IPv6.
#
# For configuring both IPv4 and IPv6 on the same interface, use two separate
# networks, and then assign both IPs to the same interface in a custom NIC
# configuration templates.
#
# The ordering of the networks below will determine the order in which NICs
# are assigned in the network/config/multiple-nics templates, beginning with
# NIC2, Control Plane is always NIC1.
- name: Storage
vip: true
vlan: 30
name_lower: storage
ip_subnet: '172.16.1.0/24'
allocation_pools: [{'start': '172.16.1.4', 'end': '172.16.1.250'}]
Remove ipv6 specific network templates This change renders the IPv6 versions of the isolated networks using j2. To allow for backward compatibility, there will be 2 versions of the network definitions, <network>.yaml and <network>_v6.yaml. If the ip_subnet contains an IPv6 address, or if ipv6: true is set on the network definition in network_data.yaml, then the <network>.yaml version will contain an IPv6 definition, otherwise the <network>.yaml will be IPv4, and the <network>_v6.yaml will be IPv6. In a future follow-up patch, we will probably only create the required versions of the networks, either IPv4, IPv6, not both. The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway settings in the network_data.yaml definition file are used for the <network>_v6.yaml network definition. Note that these subnet/cidr/gateway definitions only set the defaults, which can be overridden with parameters set in an environment file. Since the parameters for IP and subnet range are the same (e.g. InternalApiNetCidr applies to both IPv4/v6), only one version can be used at a time. If an operator wishes to use dual-stack IPv4/IPv6, then two different networks should be created, and both networks can be applied to a single interface. Note that the workflow for the operator is the same as before this change, but a new example template has been added to environments/network-environment-v6.yaml. Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc Partially-Implements: blueprint composable-networks Closes-bug: 1714115
2017-08-30 11:26:52 -07:00
ipv6_subnet: 'fd00:fd00:fd00:3000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:3000::10', 'end': 'fd00:fd00:fd00:3000:ffff:ffff:ffff:fffe'}]
mtu: 1500
- name: StorageMgmt
name_lower: storage_mgmt
vip: true
vlan: 40
ip_subnet: '172.16.3.0/24'
allocation_pools: [{'start': '172.16.3.4', 'end': '172.16.3.250'}]
Remove ipv6 specific network templates This change renders the IPv6 versions of the isolated networks using j2. To allow for backward compatibility, there will be 2 versions of the network definitions, <network>.yaml and <network>_v6.yaml. If the ip_subnet contains an IPv6 address, or if ipv6: true is set on the network definition in network_data.yaml, then the <network>.yaml version will contain an IPv6 definition, otherwise the <network>.yaml will be IPv4, and the <network>_v6.yaml will be IPv6. In a future follow-up patch, we will probably only create the required versions of the networks, either IPv4, IPv6, not both. The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway settings in the network_data.yaml definition file are used for the <network>_v6.yaml network definition. Note that these subnet/cidr/gateway definitions only set the defaults, which can be overridden with parameters set in an environment file. Since the parameters for IP and subnet range are the same (e.g. InternalApiNetCidr applies to both IPv4/v6), only one version can be used at a time. If an operator wishes to use dual-stack IPv4/IPv6, then two different networks should be created, and both networks can be applied to a single interface. Note that the workflow for the operator is the same as before this change, but a new example template has been added to environments/network-environment-v6.yaml. Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc Partially-Implements: blueprint composable-networks Closes-bug: 1714115
2017-08-30 11:26:52 -07:00
ipv6_subnet: 'fd00:fd00:fd00:4000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:4000::10', 'end': 'fd00:fd00:fd00:4000:ffff:ffff:ffff:fffe'}]
mtu: 1500
- name: InternalApi
name_lower: internal_api
vip: true
vlan: 20
ip_subnet: '172.16.2.0/24'
allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]
ipv6_subnet: 'fd00:fd00:fd00:2000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}]
mtu: 1500
- name: Tenant
vip: false # Tenant network does not use VIPs
name_lower: tenant
vlan: 50
ip_subnet: '172.16.0.0/24'
allocation_pools: [{'start': '172.16.0.4', 'end': '172.16.0.250'}]
Remove ipv6 specific network templates This change renders the IPv6 versions of the isolated networks using j2. To allow for backward compatibility, there will be 2 versions of the network definitions, <network>.yaml and <network>_v6.yaml. If the ip_subnet contains an IPv6 address, or if ipv6: true is set on the network definition in network_data.yaml, then the <network>.yaml version will contain an IPv6 definition, otherwise the <network>.yaml will be IPv4, and the <network>_v6.yaml will be IPv6. In a future follow-up patch, we will probably only create the required versions of the networks, either IPv4, IPv6, not both. The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway settings in the network_data.yaml definition file are used for the <network>_v6.yaml network definition. Note that these subnet/cidr/gateway definitions only set the defaults, which can be overridden with parameters set in an environment file. Since the parameters for IP and subnet range are the same (e.g. InternalApiNetCidr applies to both IPv4/v6), only one version can be used at a time. If an operator wishes to use dual-stack IPv4/IPv6, then two different networks should be created, and both networks can be applied to a single interface. Note that the workflow for the operator is the same as before this change, but a new example template has been added to environments/network-environment-v6.yaml. Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc Partially-Implements: blueprint composable-networks Closes-bug: 1714115
2017-08-30 11:26:52 -07:00
ipv6_subnet: 'fd00:fd00:fd00:5000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:5000::10', 'end': 'fd00:fd00:fd00:5000:ffff:ffff:ffff:fffe'}]
mtu: 1500
- name: External
vip: true
name_lower: external
vlan: 10
ip_subnet: '10.0.0.0/24'
allocation_pools: [{'start': '10.0.0.4', 'end': '10.0.0.250'}]
gateway_ip: '10.0.0.1'
ipv6_subnet: '2001:db8:fd00:1000::/64'
ipv6_allocation_pools: [{'start': '2001:db8:fd00:1000::10', 'end': '2001:db8:fd00:1000:ffff:ffff:ffff:fffe'}]
gateway_ipv6: '2001:db8:fd00:1000::1'
mtu: 1500
- name: Management
# Management network is enabled by default for backwards-compatibility, but
# is not included in any roles by default. Add to role definitions to use.
enabled: true
vip: false # Management network does not use VIPs
name_lower: management
vlan: 60
ip_subnet: '10.0.1.0/24'
allocation_pools: [{'start': '10.0.1.4', 'end': '10.0.1.250'}]
gateway_ip: '10.0.1.1'
gateway_ipv6: 'fd00:fd00:fd00:6000::1'
Remove ipv6 specific network templates This change renders the IPv6 versions of the isolated networks using j2. To allow for backward compatibility, there will be 2 versions of the network definitions, <network>.yaml and <network>_v6.yaml. If the ip_subnet contains an IPv6 address, or if ipv6: true is set on the network definition in network_data.yaml, then the <network>.yaml version will contain an IPv6 definition, otherwise the <network>.yaml will be IPv4, and the <network>_v6.yaml will be IPv6. In a future follow-up patch, we will probably only create the required versions of the networks, either IPv4, IPv6, not both. The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway settings in the network_data.yaml definition file are used for the <network>_v6.yaml network definition. Note that these subnet/cidr/gateway definitions only set the defaults, which can be overridden with parameters set in an environment file. Since the parameters for IP and subnet range are the same (e.g. InternalApiNetCidr applies to both IPv4/v6), only one version can be used at a time. If an operator wishes to use dual-stack IPv4/IPv6, then two different networks should be created, and both networks can be applied to a single interface. Note that the workflow for the operator is the same as before this change, but a new example template has been added to environments/network-environment-v6.yaml. Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc Partially-Implements: blueprint composable-networks Closes-bug: 1714115
2017-08-30 11:26:52 -07:00
ipv6_subnet: 'fd00:fd00:fd00:6000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:6000::10', 'end': 'fd00:fd00:fd00:6000:ffff:ffff:ffff:fffe'}]
mtu: 1500