Do not use direct IP allocation for isolated networks with SpecifyIpRanges - #14087
Open
nagaboinaramgopal wants to merge 1 commit into
Open
Conversation
GuestNetworkGuru.allocate() called allocateDirectIp() whenever a network had SpecifyIpRanges set, but that path allocates from the zone's VLAN public pools and is only correct for shared networks. An isolated network with SpecifyIpRanges then failed to get an address from its own CIDR and threw InsufficientAddressCapacityException once the public pools were exhausted. Gate the direct allocation on the shared guest type so isolated networks fall through to their normal CIDR allocation. Fixes: apache#12772
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
GuestNetworkGuru.allocate() called allocateDirectIp() for any network that has SpecifyIpRanges set. That path allocates from the zone's VLAN public pools and is only correct for shared networks. An isolated network with SpecifyIpRanges then tried to take an address from the public pools instead of its own CIDR, and failed with InsufficientAddressCapacityException once those pools were exhausted, even though the network's own CIDR still had free addresses.
This gates the direct allocation on the shared guest type, so isolated networks fall through to their normal CIDR allocation. Shared network behaviour is unchanged. This matches the fix suggested by weizhou in the issue.
Fixes: #12772
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
N/A
How Has This Been Tested?
Added unit tests on the base guru's allocate(). For an isolated network with SpecifyIpRanges the test checks that allocateDirectIp is not called and the address comes from the network CIDR instead; before this change that test fails because allocateDirectIp is called. For a shared network with SpecifyIpRanges the test checks that allocateDirectIp is still called, so shared allocation is unchanged.
How did you try to break this feature and the system with this change?
Kept a shared network test to make sure the direct allocation path is untouched for shared networks. The only behaviour that changes is an isolated network with SpecifyIpRanges, which now uses its own CIDR the same way an isolated network without SpecifyIpRanges already does.