Composable networks generates the environments/network-isolation.yaml and environments/network-isolation-v6.yaml files on the fly according to the network_data.yaml. If the Management network is enabled, but the management network is not enabled on a particular role (it is not enabled on any role by default), then the ports will point to network/ports/noop.yaml.
The problem is that this introduces a regression where the Management network ports won't be created if network-management.yaml is included before network-isolation.yaml (or the same with the IPv6 versions of those files). The same thing will happen with custom environment files if network-isolation[-v6].yaml is included after the custom environment.
In order to avoid this regression, the network-isolation[-v6].yaml files should not include noop.yaml references for networks that are not enabled on a role. The noop.yaml was only really required before we generated the network config, since we hard-coded the network ports in each role. The port had to exist, so noop.yaml would populate that port by reusing the control plane port.
Example:
network-isolation.yaml:
OS::TripleO::Controller::Ports::ManagementPort: ../network/ports/noop.yaml
(the above line was previously not included in the network-isolation.yaml)
network-management.yaml:
OS::TripleO::Controller::Ports::ManagementPort: ../network/ports/management.yaml
If the network-management.yaml is included before the network-isolation.yaml, this assignment will be overwritten with noop.yaml, and the management network will not work.
We shouldn't need to use noop.yaml at all in the network environment files. We already set all ports to noop.yaml in the role definitions and overcloud-resource-registry.yaml that are generated on the fly. Doing the same thing in the environment files introduces the order-of-operation issue when including environment files.
To clarify, wasn't this always order dependent, as we previously had hard-coded noops in the network-