Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
Chapter 7. Isolating Networks
The director provides methods to configure isolated Overcloud networks. This means the Overcloud environment separates network traffic types into different networks, which in turn assigns network traffic to specific network interfaces or bonds. After configuring isolated networks, the director configures the OpenStack services to use the isolated networks. If no isolated networks are configured, all services run on the Provisioning network.
This example uses separate networks for all services:
NIC1 (Provisioning):
- Provisioning (also known as Control Plane)
NIC2 (Control Group)
- Internal API
- Storage Management
- External (Public API)
NIC3 (Data Group)
- Tenant Network (VXLAN tunneling)
- Tenant VLANs / Provider VLANs
- Storage
- External VLANs (Floating IP/SNAT)
NIC4 (Management)
- Management
In this example, each Overcloud node uses two network interfaces in a bond to serve networks in tagged VLANs. The following network assignments apply to this bond:
Table 7.1. Network Subnet and VLAN Assignments
Network Type | Subnet | VLAN | NIC/Group |
---|---|---|---|
Internal API | 172.16.0.0/24 | 201 | NIC2 (control) |
Tenant | 172.17.0.0/24 | 202 | NIC3 (data) |
Storage | 172.18.0.0/24 | 203 | NIC3 (data) |
Storage Management | 172.19.0.0/24 | 204 | NIC2 (control) |
Management | 172.20.0.0/24 | 205 | NIC4 (management) |
External / Floating IP | 10.1.1.0/24 | 100 | NIC2 (control) NIC3 (data) |
7.1. Creating Custom Interface Templates
The Overcloud network configuration requires a set of the network interface templates. You customize these templates to configure the node interfaces on a per role basis. These templates are standard Heat templates in YAML format (see Section 2.1, “Heat Templates”). The director contains a set of example templates to get you started:
-
/usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans
- Directory containing templates for single NIC with VLANs configuration on a per role basis. -
/usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans
- Directory containing templates for bonded NIC configuration on a per role basis. -
/usr/share/openstack-tripleo-heat-templates/network/config/multiple-nics
- Directory containing templates for multiple NIC configuration using one NIC per role. -
/usr/share/openstack-tripleo-heat-templates/network/config/single-nic-linux-bridge-vlans
- Directory containing templates for single NIC with VLANs configuration on a per role basis and using a Linux bridge instead of an Open vSwitch bridge.
These examples only contain templates for the default roles. To define the network interface configuration for a custom role, use these templates as a basis.
For this example, use the default multiple NICs example configuration as a basis. Copy the version located at /usr/share/openstack-tripleo-heat-templates/network/config/multiple-nics
.
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/multiple-nics ~/templates/nic-configs
The command will create a local set of Heat templates that define a network interface configuration with multiple NICs for each role. Each template contains the standard parameters
, resources
, and output
sections.
Parameters
The parameters
section contains all network configuration parameters for network interfaces. This includes information such as subnet ranges and VLAN IDs. This section should remain unchanged as the Heat template inherits values from its parent template. However, you can modify the values for some parameters using environment files.
Parameter | Description | Type |
---|---|---|
| The node’s IP address and subnet on the Control Plane/Provisioning network | string |
| The node’s IP address and subnet on the External network | string |
| The node’s IP address and subnet on the Internal API network | string |
| The node’s IP address and subnet on the Storage network | string |
| The node’s IP address and subnet on the Storage Management network | string |
| The node’s IP address and subnet on the Tenant network | string |
|
The node’s IP address and subnet on the Management network. Only populated when including | string |
| The node’s VLAN ID for External network traffic. | number |
| The node’s VLAN ID for Internal API network traffic. | number |
| The node’s VLAN ID for Storage network traffic. | number |
| The node’s VLAN ID for Storage Management network traffic. | number |
| The node’s VLAN ID for Tenant network traffic. | number |
| The node’s VLAN ID for Management network traffic. | number |
|
The default route of the Control Plane/Provisioning network. Override this in the | string |
| The default route for the External network. | string |
| The default route of the Management network. | string |
|
The subnet CIDR of the Control Plane/Provisioning network. Override this in the | string |
|
A list of DNS servers added to resolv.conf. Usually allows a maximum of 2 servers. Override this in the | comma delimited list |
|
The IP address of the EC2 metadata server. Override this in the | string |
Resources
The resources
section is where the main network interface configuration occurs. In most cases, the resources
section is the only one that requires editing. Each resources
section begins with the following header:
resources: OsNetConfigImpl: type: OS::Heat::SoftwareConfig properties: group: script config: str_replace: template: get_file: ../../scripts/run-os-net-config.sh params: $network_config: network_config:
This runs a script (run-os-net-config.sh
) that creates a configuration file for os-net-config
to use for configuring network properties on a node. The network_config
section contains the custom network interface data sent to the run-os-net-config.sh
script. You arrange this custom interface data in a sequence based on the type of device, which includes the following:
- interface
Defines a single network interface. The configuration defines each interface using either the actual interface name ("eth0", "eth1", "enp0s25") or a set of numbered interfaces ("nic1", "nic2", "nic3").
- type: interface name: nic2
- vlan
Defines a VLAN. Use the VLAN ID and subnet passed from the
parameters
section.- type: vlan vlan_id:{get_param: ExternalNetworkVlanID} addresses: - ip_netmask: {get_param: ExternalIpSubnet}
- ovs_bond
Defines a bond in Open vSwitch to join two or more
interfaces
together. This helps with redundancy and increases bandwidth.- type: ovs_bond name: bond1 members: - type: interface name: nic2 - type: interface name: nic3
- ovs_bridge
Defines a bridge in Open vSwitch, which connects multiple
interface
,ovs_bond
, andvlan
objects together. The external bridge also uses two special values for parameters:-
bridge_name
, which is replaced with the external bridge name. interface_name
, which is replaced with the external interface.- type: ovs_bridge name: bridge_name addresses: - ip_netmask: list_join: - / - - {get_param: ControlPlaneIp} - {get_param: ControlPlaneSubnetCidr} members: - type: interface name: interface_name - type: vlan device: bridge_name vlan_id: {get_param: ExternalNetworkVlanID} addresses: - ip_netmask: {get_param: ExternalIpSubnet}
-
The OVS bridge connects to the Neutron server in order to get configuration data. If the OpenStack control traffic (typically the Control Plane and Internal API networks) is placed on an OVS bridge, then connectivity to the Neutron server gets lost whenever OVS is upgraded or the OVS bridge is restarted by the admin user or process. This will cause some downtime. If downtime is not acceptable under these circumstances, then the Control group networks should be placed on a separate interface or bond rather than on an OVS bridge:
- A minimal setting can be achieved, when you put the Internal API network on a VLAN on the provisioning interface and the OVS bridge on a second interface.
- If you want bonding, you need at least two bonds (four network interfaces). The control group should be placed on a Linux bond (Linux bridge). If the switch does not support LACP fallback to a single interface for PXE boot, then this solution requires at least five NICs.
- linux_bond
Defines a Linux bond that joins two or more
interfaces
together. This helps with redundancy and increases bandwidth. Make sure to include the kernel-based bonding options in thebonding_options
parameter. For more information on Linux bonding options, see 4.5.1. Bonding Module Directives in the Red Hat Enterprise Linux 7 Networking Guide.- type: linux_bond name: bond1 members: - type: interface name: nic2 - type: interface name: nic3 bonding_options: "mode=802.3ad"
- linux_bridge
Defines a Linux bridge, which connects multiple
interface
,linux_bond
, andvlan
objects together. The external bridge also uses two special values for parameters:-
bridge_name
, which is replaced with the external bridge name. interface_name
, which is replaced with the external interface.- type: linux_bridge name: bridge_name addresses: - ip_netmask: list_join: - / - - {get_param: ControlPlaneIp} - {get_param: ControlPlaneSubnetCidr} members: - type: interface name: interface_name - type: vlan device: bridge_name vlan_id: {get_param: ExternalNetworkVlanID} addresses: - ip_netmask: {get_param: ExternalIpSubnet}
-
See Chapter 17, Network Interface Parameters for a full list of parameters for each of these items.
The following settings are based on default controller template from the /home/stack/templates/nic-configs/controller.yaml
file. The networks (network-config
) were configured according to the previous recommendations to keep the control group apart from the OVS bridge:
resources: OsNetConfigImpl: type: OS::Heat::SoftwareConfig properties: group: script config: str_replace: template: get_file: ../../scripts/run-os-net-config.sh params: $network_config: network_config: # NIC 1 - Provisioning - type: interface name: nic1 use_dhcp: false addresses: - ip_netmask: list_join: - / - - get_param: ControlPlaneIp - get_param: ControlPlaneSubnetCidr routes: - ip_netmask: 169.254.169.254/32 next_hop: get_param: EC2MetadataIp # NIC 2 - Control Group - type: interface name: nic2 use_dhcp: false - type: vlan device: nic2 vlan_id: get_param: InternalApiNetworkVlanID addresses: - ip_netmask: get_param: InternalApiIpSubnet - type: vlan device: nic2 vlan_id: get_param: StorageMgmtNetworkVlanID addresses: - ip_netmask: get_param: StorageMgmtIpSubnet - type: vlan device: nic2 vlan_id: get_param: ExternalNetworkVlanID addresses: - ip_netmask: get_param: ExternalIpSubnet routes: - default: true next_hop: get_param: ExternalInterfaceDefaultRoute # NIC 3 - Data Group - type: ovs_bridge name: bridge_name dns_servers: get_param: DnsServers members: - type: interface name: nic3 primary: true - type: vlan device: nic3 vlan_id: get_param: StorageNetworkVlanID addresses: - ip_netmask: get_param: StorageIpSubnet - type: vlan device: nic3 vlan_id: get_param: TenantNetworkVlanID addresses: - ip_netmask: get_param: TenantIpSubnet # NIC 4 - Management - type: interface name: nic4 use_dhcp: false addresses: - ip_netmask: {get_param: ManagementIpSubnet} routes: - default: true next_hop: {get_param: ManagementInterfaceDefaultRoute}
The Management network section is commented in the network interface Heat templates. Uncomment this section to enable the Management network.
This template uses four network interfaces and assigns a number of tagged VLAN devices to the numbered interfaces, nic1
to nic4
. On nic3
it creates the OVS bridge that hosts the Storage and Tenant networks.
For more examples of network interface templates, see Appendix B, Network Interface Template Examples.
Unused interfaces can cause unwanted default routes and network loops. For example, your template might contain a network interface (nic4
) that does not use any IP assignments for OpenStack services but still uses DHCP and/or a default route. To avoid network conflicts, remove any unused interfaces from ovs_bridge
devices and disable the DHCP and default route settings:
- type: interface name: nic4 use_dhcp: false defroute: false
7.2. Creating a Network Environment File
The network environment file is a Heat environment file that describes the Overcloud’s network environment and points to the network interface configuration templates from the previous section. You can define the subnets and VLANs for your network along with IP address ranges. You can then customize these values for the local environment.
The director contains a set of example environment files to get you started. Each environment file corresponds to the example network interface files in /usr/share/openstack-tripleo-heat-templates/network/config/
:
-
/usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml
- Example environment file for single NIC with VLANs configuration in thesingle-nic-vlans
) network interface directory. Environment files for disabling the External network (net-single-nic-with-vlans-no-external.yaml
) or enabling IPv6 (net-single-nic-with-vlans-v6.yaml
) are also available. -
/usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml
- Example environment file for bonded NIC configuration in thebond-with-vlans
network interface directory. Environment files for disabling the External network (net-bond-with-vlans-no-external.yaml
) or enabling IPv6 (net-bond-with-vlans-v6.yaml
) are also available. -
/usr/share/openstack-tripleo-heat-templates/environments/net-multiple-nics.yaml
- Example environment file for a multiple NIC configuration in themultiple-nics
network interface directory. An environment file for enabling IPv6 (net-multiple-nics-v6.yaml
) is also available. -
/usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-linux-bridge-with-vlans.yaml
- Example environment file for single NIC with VLANs configuration using a Linux bridge instead of an Open vSwitch bridge, which uses the thesingle-nic-linux-bridge-vlans
network interface directory.
This scenario uses a modified version of the /usr/share/openstack-tripleo-heat-templates/environments/net-multiple-nics.yaml
file. Copy this file to the stack user’s templates
directory.
$ cp /usr/share/openstack-tripleo-heat-templates/environments/net-multiple-nics.yaml /home/stack/templates/network-environment.yaml
The environment file contains the following modified sections:
resource_registry: OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/cinder-storage.yaml OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/swift-storage.yaml OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/ceph-storage.yaml parameter_defaults: InternalApiNetCidr: 172.16.0.0/24 TenantNetCidr: 172.17.0.0/24 StorageNetCidr: 172.18.0.0/24 StorageMgmtNetCidr: 172.19.0.0/24 ManagementNetCidr: 172.20.0.0/24 ExternalNetCidr: 10.1.1.0/24 InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}] TenantAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}] StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}] StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}] ManagementAllocationPools: [{'start': '172.20.0.10', 'end': '172.20.0.200'}] # Leave room for floating IPs in the External allocation pool ExternalAllocationPools: [{'start': '10.1.1.10', 'end': '10.1.1.50'}] # Set to the router gateway on the external network ExternalInterfaceDefaultRoute: 10.1.1.1 # Gateway router for the provisioning network (or Undercloud IP) ControlPlaneDefaultRoute: 192.0.2.254 # The IP address of the EC2 metadata server. Generally the IP of the Undercloud EC2MetadataIp: 192.0.2.1 # Define the DNS servers (maximum 2) for the overcloud nodes DnsServers: ["8.8.8.8","8.8.4.4"] InternalApiNetworkVlanID: 201 StorageNetworkVlanID: 202 StorageMgmtNetworkVlanID: 203 TenantNetworkVlanID: 204 ManagementNetworkVlanID: 205 ExternalNetworkVlanID: 100 NeutronExternalNetworkBridge: "''"
The resource_registry
section contains modified links to the custom network interface templates for each node role. Also include links to network interface template for custom roles in this section using the following format:
-
OS::TripleO::[ROLE]::Net::SoftwareConfig: [FILE]
Replace [ROLE]
with the role name and [FILE]
with the network interface template location.
The parameter_defaults
section contains a list of parameters that define the network options for each network type. For a full reference of these options, see Appendix A, Network Environment Options.
This scenario defines options for each network. All network types use an individual VLAN and subnet used for assigning IP addresses to hosts and virtual IPs. In the example above, the allocation pool for the Internal API network starts at 172.16.0.10 and continues to 172.16.0.200 using VLAN 201. This results in static and virtual IPs assigned starting at 172.16.0.10 and upwards to 172.16.0.200 while using VLAN 201 in your environment.
The External network hosts the Horizon dashboard and Public API. If using the External network for both cloud administration and floating IPs, make sure there is room for a pool of IPs to use as floating IPs for VM instances. In this example, you only have IPs from 10.1.1.10 to 10.1.1.50 assigned to the External network, which leaves IP addresses from 10.1.1.51 and above free to use for Floating IP addresses. Alternately, place the Floating IP network on a separate VLAN and configure the Overcloud after creation to use it.
If using bonded OVS interfaces, you can configure additional options with BondInterfaceOvsOptions
. See Appendix C, Open vSwitch Bonding Options for more information.
Changing the network configuration after creating the Overcloud can cause configuration problems due to the availability of resources. For example, if a user changes a subnet range for a network in the network isolation templates, the reconfiguration might fail due to the subnet already being in use.
7.3. Assigning OpenStack Services to Isolated Networks
Each OpenStack service is assigned to a default network type in the resource registry. These services are then bound to IP addresses within the network type’s assigned network. Although the OpenStack services are divided among these networks, the number of actual physical networks might differ as defined in the network environment file. You can reassign OpenStack services to different network types by defining a new network map in your network environment file (/home/stack/templates/network-environment.yaml
). The ServiceNetMap
parameter determines the network types used for each service.
For example, you can reassign the Storage Management network services to the Storage Network by modifying the highlighted sections:
parameter_defaults: ServiceNetMap: SwiftMgmtNetwork: storage # Changed from storage_mgmt CephClusterNetwork: storage # Changed from storage_mgmt
Changing these parameters to storage
places these services on the Storage network instead of the Storage Management network. This means you only need to define a set of parameter_defaults
for the Storage network and not the Storage Management network.
The director merges your custom ServiceNetMap
parameter definitions into a pre-defined list of defaults taken from ServiceNetMapDefaults
and overrides the defaults. The director then returns the full list including customizations back to ServiceNetMap
, which is used to configure network assignments for various services.
A full list of default services can be found in the ServiceNetMapDefaults
parameter within /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml
.
7.4. Selecting Networks to Deploy
The settings in the resource_registry
section of the environment file for networks and ports do not ordinarily need to be changed. The list of networks can be changed if only a subset of the networks are desired.
When specifying custom networks and ports, do not include the environments/network-isolation.yaml
on the deployment command line. Instead, specify all the networks and ports in the network environment file.
In order to use isolated networks, the servers must have IP addresses on each network. You can use neutron in the Undercloud to manage IP addresses on the isolated networks, so you will need to enable neutron port creation for each network. You can override the resource registry in your environment file.
First, this is the complete set of the default networks and ports per role that can be deployed:
resource_registry: # This section is usually not modified, if in doubt stick to the defaults # TripleO overcloud networks OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml OS::TripleO::Network::StorageMgmt: /usr/share/openstack-tripleo-heat-templates/network/storage_mgmt.yaml OS::TripleO::Network::Storage: /usr/share/openstack-tripleo-heat-templates/network/storage.yaml OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml OS::TripleO::Network::Management: /usr/share/openstack-tripleo-heat-templates/network/management.yaml # Port assignments for the VIPs OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml OS::TripleO::Network::Ports::TenantVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml OS::TripleO::Network::Ports::ManagementVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml # Port assignments for the controller role OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml OS::TripleO::Controller::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml # Port assignments for the compute role OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml OS::TripleO::Compute::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml # Port assignments for the ceph storage role OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml OS::TripleO::CephStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml # Port assignments for the swift storage role OS::TripleO::SwiftStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::SwiftStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml OS::TripleO::SwiftStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml # Port assignments for the block storage role OS::TripleO::BlockStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::BlockStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::BlockStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml OS::TripleO::BlockStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
The first section of this file has the resource registry declaration for the OS::TripleO::Network::*
resources. By default these resources use the OS::Heat::None
resource type, which does not create any networks. By redirecting these resources to the YAML files for each network, you enable the creation of these networks.
The next several sections create the IP addresses for the nodes in each role. The controller nodes have IPs on each network. The compute and storage nodes each have IPs on a subset of the networks.
The default file only contains the port assignments for the default roles. To configure port assignments for a custom role, use the same convention as the other resource definitions and link to the appropriate Heat templates in the network/ports
directory:
-
OS::TripleO::[ROLE]::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
-
OS::TripleO::[ROLE]::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
-
OS::TripleO::[ROLE]::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
-
OS::TripleO::[ROLE]::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
-
OS::TripleO::[ROLE]::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
-
OS::TripleO::[ROLE]::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
Replace [ROLE]
with the name of your role.
To deploy without one of the pre-configured networks, disable the network definition and the corresponding port definition for the role. For example, all references to storage_mgmt.yaml
could be replaced with OS::Heat::None
:
resource_registry: # This section is usually not modified, if in doubt stick to the defaults # TripleO overcloud networks OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml OS::TripleO::Network::StorageMgmt: OS::Heat::None OS::TripleO::Network::Storage: /usr/share/openstack-tripleo-heat-templates/network/storage.yaml OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml # Port assignments for the VIPs OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Network::Ports::StorageMgmtVipPort: OS::Heat::None OS::TripleO::Network::Ports::TenantVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml # Port assignments for the controller role OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Controller::Ports::StorageMgmtPort: OS::Heat::None OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml # Port assignments for the compute role OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml # Port assignments for the ceph storage role OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::CephStorage::Ports::StorageMgmtPort: OS::Heat::None # Port assignments for the swift storage role OS::TripleO::SwiftStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::SwiftStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: OS::Heat::None # Port assignments for the block storage role OS::TripleO::BlockStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::BlockStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::BlockStorage::Ports::StorageMgmtPort: OS::Heat::None parameter_defaults: ServiceNetMap: ApacheNetwork: internal_api NeutronTenantNetwork: tenant CeilometerApiNetwork: internal_api ContrailAnalyticsNetwork: internal_api ContrailAnalyticsDatabaseNetwork: internal_api ContrailConfigNetwork: internal_api ContrailControlNetwork: internal_api ContrailDatabaseNetwork: internal_api ContrailWebuiNetwork: internal_api ContrailTsnNetwork: internal_api AodhApiNetwork: internal_api PankoApiNetwork: internal_api BarbicanApiNetwork: internal_api GnocchiApiNetwork: internal_api MongodbNetwork: internal_api CinderApiNetwork: internal_api CinderIscsiNetwork: storage CongressApiNetwork: internal_api GlanceApiNetwork: internal_api IronicApiNetwork: ctlplane IronicNetwork: ctlplane KeystoneAdminApiNetwork: ctlplane # allows undercloud to config endpoints KeystonePublicApiNetwork: internal_api ManilaApiNetwork: internal_api NeutronApiNetwork: internal_api OctaviaApiNetwork: internal_api HeatApiNetwork: internal_api HeatApiCfnNetwork: internal_api HeatApiCloudwatchNetwork: internal_api NovaApiNetwork: internal_api NovaColdMigrationNetwork: ctlplane NovaPlacementNetwork: internal_api NovaMetadataNetwork: internal_api NovaVncProxyNetwork: internal_api NovaLibvirtNetwork: internal_api Ec2ApiNetwork: internal_api Ec2ApiMetadataNetwork: internal_api TackerApiNetwork: internal_api SwiftStorageNetwork: storage # Changed from storage_mgmt SwiftProxyNetwork: storage SaharaApiNetwork: internal_api HorizonNetwork: internal_api MemcachedNetwork: internal_api RabbitmqNetwork: internal_api RedisNetwork: internal_api MysqlNetwork: internal_api CephClusterNetwork: storage # Changed from storage_mgmt CephMonNetwork: storage CephRgwNetwork: storage PublicNetwork: external OpendaylightApiNetwork: internal_api OvnDbsNetwork: internal_api MistralApiNetwork: internal_api ZaqarApiNetwork: internal_api PacemakerRemoteNetwork: internal_api EtcdNetwork: internal_api CephStorageHostnameResolveNetwork: storage ControllerHostnameResolveNetwork: internal_api ComputeHostnameResolveNetwork: internal_api ObjectStorageHostnameResolveNetwork: internal_api BlockStorageHostnameResolveNetwork: internal_api
By using OS::Heat::None
, no network or ports are created, so the services on the Storage Management network would default to the Provisioning network. This can be changed in the ServiceNetMap
in order to move the Storage Management services to another network, such as the Storage network.