Comment 14 for bug 1543094

@John - You make an interesting point. I think maybe we should consider starting this as an alternate experimental driver. But, we should weigh this against the difficulties of supporting multiple drivers.

If it is just to avoid having to fix unit tests, then I'd say that it isn't worth it to support two different drivers. Ignoring unit tests and other internal development reasons, is there really a compelling reason to continue to support the current behavior? Why would someone care if they get the next available IP address sequentially or if they get one of the N lowest available IP addresses? If it is just OCD, then I'd say there is no compelling reason. But, maybe you know of a reason.

@Pavel. I agree with you. But, the more I think through it, the more I think that the cost really isn't a big deal. We've found that by simplifying the DB queries we actually reduce the number of queries when there are multiple subnets thus reducing the round trips to the DB.

The worst case is a network with thousands of allocations. If there are this many allocations, they are likely from multiple subnets. So, compare the time it takes to query that many allocations and add them to an IPSet in memory in one shot with the time it takes to make multiple queries to the DB. I really don't think it will be bad. And, if we remove the contention, we won't have to pay for retries nearly as much. With that said, maybe we should develop this as a separate driver and find a deployment with thousands of allocations in a single network to measure how this behaves. Then, when it is ready, we can replace the current driver.