Comment 16 for bug 1843211

I did some additional testing and thinking and I disagree with the conclusion in #15 that this behavior is a bug for the following reasons:

1) When we set a subnet to --no-allocation-pool, we are not saying that the subnet doesn't have available IPs anymore. What we are saying is that we don't have a pool or pools inside the subnet's CIDR from which to automatically allocate IPs when the port create request doesn't specify explicitly an address. Please look at http://paste.openstack.org/show/780902/. Once I set the subnet to --no-allocation pool I need to explicitly specify an ip address to create a port in that subnet. Also note in http://paste.openstack.org/show/780902/ that the accounting of available IPs is correct after the subnet has been set to --no-allocation-pool

2) Now let's look at the code: https://github.com/openstack/neutron/blob/92f7484d2a59f0ee900eca7280f92f6c1c0de35e/neutron/db/network_ip_availability_db.py#L125-L139. This code explicitly and prominently distinguishes between the case where the subnet has allocation pools (L132-136) which are then used for the IP availability calculation, and the case where the allocation pools are absent. In the latter case, the IP availability calculation is based on the subnet's CIDR (L138-139). Note that this loop iterates over a query generated here https://github.com/openstack/neutron/blob/92f7484d2a59f0ee900eca7280f92f6c1c0de35e/neutron/db/network_ip_availability_db.py#L107-L115. Based on this code, the semantics of the network-ip-availability extension is the following in regards to subnet allocation pools: if there are allocation pools, we will base the calculations on them. If there aren't we will use the subnet's CIDR. These semantics might need to be better documented, but that doesn't mean we have a bug in the code.

3) Please also note that the loop mentioned in the previous point hasn't changed since the code was originally merged: https://review.opendev.org/#/c/212955/23/neutron/db/network_ip_availability_db.py@124

4) Look at the patch that implemented the network-ip-availability extension: https://review.opendev.org/#/c/212955. The developers are from GoDaddy. They also submitted the original RFE (https://bugs.launchpad.net/neutron/+bug/1457986) and wrote the spec (https://review.opendev.org/#/c/180803/). GoDaddy is a BIG OpenStack deployer with an $11B market cap (https://finance.yahoo.com/quote/GDDY?p=GDDY&.tsrc=fin-srch). So we know that at least they have tooling based on the current behavior of network-ip-availability. And it is very likely that other deployers rely on this behavior, since the code was merged almost 3 years and a half ago (March 1 2016). Are we going to risk breaking them?

5) Finally, I am confused about the submitter's intent with this bug. If he sets the subnet to --no-allocation-pool, why is he surprised that he cannot create a port without explicitly specifying an address, as he seems to be in #1? That's the expected behavior and as mentioned in my point 1, network-ip-availability does the correct accounting