IPv6 availability ranges now grow without bounds

[Jeremy Hanmer]

Thanks to the new method of lazily recycling IPs introduced in Ia55b66128de9986e075b0f87acc401d211cd91d3 the allocation availability range tables in the database grow without any bounds and result in a *huge* performance impact on neutron's overall functionality.

Case in point, this is the db contents after creating and destroying 5 VMs with IPv6 addresses:

mysql> select * from ipavailabilityranges where allocation_pool_id in ('10f63364-0541-4b55-8372-582bcfa25cdc','06399db3-6212-42ec-bcaa-919b5ec48e73');
+--------------------------------------+---------------------------------------+---------------------------------------+
| allocation_pool_id | first_ip | last_ip |
+--------------------------------------+---------------------------------------+---------------------------------------+
| 06399db3-6212-42ec-bcaa-919b5ec48e73 | 2607:f298:7000:9e::2 | 2607:f298:7000:9e:f816:3eff:fe12:396f |
| 06399db3-6212-42ec-bcaa-919b5ec48e73 | 2607:f298:7000:9e:f816:3eff:fe12:3971 | 2607:f298:7000:9e:f816:3eff:fe14:24ed |
| 06399db3-6212-42ec-bcaa-919b5ec48e73 | 2607:f298:7000:9e:f816:3eff:fe14:24ef | 2607:f298:7000:9e:f816:3eff:fe4a:4d15 |
| 06399db3-6212-42ec-bcaa-919b5ec48e73 | 2607:f298:7000:9e:f816:3eff:fe4a:4d17 | 2607:f298:7000:9e:f816:3eff:fe97:9c7e |
| 06399db3-6212-42ec-bcaa-919b5ec48e73 | 2607:f298:7000:9e:f816:3eff:fe97:9c80 | 2607:f298:7000:9e:f816:3eff:fec1:cfa0 |
| 06399db3-6212-42ec-bcaa-919b5ec48e73 | 2607:f298:7000:9e:f816:3eff:fec1:cfa2 | 2607:f298:7000:9e:ffff:ffff:ffff:fffe |
| 10f63364-0541-4b55-8372-582bcfa25cdc | 10.10.10.148 | 10.10.10.254 |
+--------------------------------------+---------------------------------------+---------------------------------------+

Because these ranges are checked while doing such things as "neutron net-list", this pretty quickly becomes a large performance problem. After this change was applied, just a couple of days of creating and destroying VMs via automated testing caused the time it took for an admin to run "neutron net-list" to go from just a couple of seconds to over 20 seconds.

[Carl Baldwin (carl-baldwin)]

So, before lazy recycling, the availability ranges would be cleaned up and now they're not.

What we need to do is to stop using availability ranges where SLAAC is being used to allocate IP addresses. They aren't being used for anything anyway.

[Xu Han Peng (xuhanp)]

In currently code, ipavailabilityranges changes only happen when "ip_address" is specified in fixed_ip. Since SLAAC subnet doesn't need fixed_ip address specified for a port, the SLAAC address is not recorded in ipavailabilityranges.

[Armando Migliaccio (armando-migliaccio)]

This bug is > 172 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]