Bug 1516670

Description of problem:
When a GUI user uploads a custom network-environment.yaml file and chooses it along with the network-isolation.yaml in the plan configuration dialog, there is no way to tell the system what the correct order is to include the environment files and which file precedes which.

When deploying from the GUI the order always comes out backwards, so the customizations in network-environment.yaml get overwritten and reverted back to the defaults in network-isolation.yaml (the last file that's parsed is the one that counts).

For example, in my bare metal setup, I have to configure the tenant network to noop in order to create this network on the ctlplane (because our IT couldn't allocate me all the networks I asked from them on our corporate network). When I deploy from the GUI, the mapping to noop gets overwritten, and the deployments fail because they can't ping addresses on the tenant network (this network is not in my nic-configs because I map it to noop).

A similar problem will happen to GUI users who want to use the predictable IP feature... Any mapping of networks or ports to different classes in heat will get overwritten if the order of inclusion of the environment files is backwards.


How reproducible:
100%


Steps to Reproduce:
1. Deploy with network isolation. Map several resources to None and noop.
2. Check if the default mappings were used instead of you r customizations. If deployment failed - it's probably because of the network misconfigurations in the resources you mapped.


Additional info:
The ugly way to work around this is to concat your customizations to network-isolation.yaml, and put them in the end of the file so you know they'll take precedence. Then you don't include network-environment.yaml in the customization at all. But you pay a price: the validator of the network configuration parses the netowrk-environment.yaml file, and this workaround will also work around the validator.