* Description of problem: I understand that it is not currently possible to deploy an overcloud which has the same subnet (e.g. 172.16.3.0/24) provide two different roles (InternalApiNetCidr and StorageNetCidr). For example, if I had the following in my network-environment.yaml file then I'd hope I could deploy some network isolation but not full network isolation. InternalApiNetCidr: 172.16.3.0/24 # em1 (3) StorageNetCidr: 172.16.3.0/24 # em1 (3) StorageMgmtNetCidr: 172.16.3.0/24 # em1 (3) TenantNetCidr: 172.16.2.0/24 # em2 (2) ExternalNetCidr: 172.16.2.0/24 # em2 (2) * Version-Release number of selected component (if applicable): beta 2 * How reproducible: deterministic. * Steps to Reproduce: 1. Deploy an overcloud using a network.yaml like the example above 2. You will not get the desired results Actual results: This feature is not supported so you won't be able to have the network roles for InternalApiNetCidr and StorageNetCidr on the same subnet. Expected results: InternalApiNetCidr and StorageNetCidr can use the same subnet. Additional info: OSP-Installer let you do this. One could: """ Drag the Tenant, Management, Cluster Management, Admin API, Public API, Storage, and Storage Clustering network traffic types onto the OpenStack Services subnet (e.g. 10.1.2.0/24) created in Section 4.2.2, “Creating an OpenStack Services Subnet”. """ As per https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html/Installer_and_Foreman_Guide/sect-Creating_a_Deployment_for_an_Advanced_Environment.html which included the following screen cap to demonstrate the idea: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html/Installer_and_Foreman_Guide/images/6536.png
(In reply to John Fulton from comment #0) I think there is a misunderstanding of the way that OSP-Director distributes traffic. If the desire is to combine the Storage, Storage Management, and Internal API networks, that can be done. However, the way to do this isn't to assign multiple isolated networks to the same interface. One can achieve the desired result by doing collapsing the network functions onto a smaller number of networks: 1) Enable only the Storage and Tenant isolated networks 2) Using the ServiceNetMap, assign all functions from the storage_mgmt and internal_api networks to the storage network 3) The External network with the Public API will default to staying on the provisioning interface (I'm assuming there is a separate provisioning interface that wasn't mentioned). One might be able to combine the External and Tenant networks if that's really what's desired (but it hasn't been tested).
John, Based upon Dan's feedback in comment 4, is your request satisfied?
Chris, Yes. Thanks. --John
(In reply to John Fulton from comment #6) > Chris, Yes. Thanks. --John Great. Just ping me if you need help constructing a custom network-environment.yaml and the associated NIC configs for your environment.