When an operator configured multiple network VLAN ranges, we
had no guarantee that we would actually allocate in the order
specified like we do with segmentation types. In *most* cases,
the natural database order would be that the returned available
segment IDs would come back in the order of the physnets because
the sync_allocations code inserted them in that order. So it
became something some deployments would rely on and operators
would get a surprise when suddenly an allocation would happen
from the later physnets while many VLANs were still available
in the first one.
This patch just strictly makes allocation attempts in the order
of the network_vlan_ranges so operators are always guaranteed that
the later physnets will not automatically be allocated from unless
the earlier physnets are exhausted.
Change-Id: I14ca9b7e1141199f3ec221184fbbe156f1f9e18b
c5662c86a4