When trying to assign new IPs Nailgun iters over all IPs in DB

[Andrey Danin]

4.1
The method NetworkManager._iter_free_ips() doesn't use NetworkGroup.id when iterating over already used IPs in DB. So if you have another cluster with same networks, the method will exclude IPs of the old one cluster from its output. Theoretically it may lead to "Not enough free IPs" error.

For instance:
1) Create a cluster A, Simple NovaNet, with Public network set to 172.16.0.0/29 and range set to 172.16.0.2-172.16.0.6.
2) Populate this cluster A with 4 nodes.
3) Call an API URL /api/clusters/A/orchestrator/deployment/defaults
3.a) It assigns all necessary IPs and returns a JSON with deployment data.
4) Create a cluster B, Simple Neutron, with Public network 172.16.0.2-172.16.0.6 netmask 255.255.255.240 and floating range 172.16.0.7-172.16.0.14.
5) Populate the cluster B with 2 nodes.
6) Call an API URL /api/clusters/A/orchestrator/deployment/defaults

Expected result:
It returns a JSON with deployment data.
Real result:
HTTP 500 "Internal server error"

You can easily reproduce it on the fake UI.

The problem is here https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/network/manager.py#L316
Just add 'filter_by(network == network_group.id)' to the query.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/78232

[Andrew Woodward (xarses)]

This is absolutely not what we want do. This will make it easy for users to deploy multiple clouds with conflicting networking information. There is no use case where a user will ever want to deploy duplicate public addresses.

There are a small set of cases where I could envision a user deploying duplicate storage and management ranges but, there is almost no chance for them to be managed by the same fuel server. Even in these cases, additional attributes need to be established to ensure that the networks are in-fact separate such as vlan-tag or positive assertion from the user that this is desired.

As the patch currently stands it should not be accepted as it creates unnecessary risk that we are currently preventing.