pool: Randomize mac #447
Open
pool: Randomize mac #447
+340
−234
Conversation
This file contains 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
Signed-off-by: Ram Lavi <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
RamLavi
force-pushed
the
randomize-mac
branch
from
b3e20f2 to
6c9452b
Compare
The networks and network-status annotations consts are set on multus repo, and controlled by it. Using their consts to keep consistency. Signed-off-by: Ram Lavi <[email protected]>
There is no good reason to use these functions as closure functions. Moving them to be regular functions, thus reducing code complexity. Signed-off-by: Ram Lavi <[email protected]>
Currently not all unit tests check macpool size after doing changes in the macpool map (allocate, update or delete MACs entries) Moving the check inside checkMacPoolMapEntries so that all tests check this, removing the now redundant checks. Also refactoring use of "errors.New(fmt.Sprintf(...))" into "fmt.Errorf(...)" Signed-off-by: Ram Lavi <[email protected]>
Previously, the MAC allocation strategy relied on sequential assignment. The system kept track of the last allocated MAC and assigned the next sequential MAC unless it was already in use. This approach can cause issues in specific use cases where multi-clusters are merged into one, increasing the likelihood of MAC conflict. Changing the algorithm to be random to ensure more robust MAC allocation for dynamic and distributed environments. Fix unit tests appropriately, and also add unit test for full MAC Pool. Signed-off-by: Ram Lavi <[email protected]>
Since now MAC allocation is done randomly, it is better to increase the MAC pool range to be large, to greatly reduce cases where the randomly allocated MAC is the one accidentally expected by the tests. Also change managedNamespaceMAC, unmanagedNamespaceMAC to be outside of this range to reduce rare cases where the MAC allocator will assign that MAC to the interfaces, creating a forbidden duplication. Signed-off-by: Ram Lavi <[email protected]>
RamLavi
force-pushed
the
randomize-mac
branch
from
6c9452b to
d5d2916
Compare
|
/hold |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What this PR does / why we need it:
Currently, the MAC allocation strategy relied on sequential assignment.
The system kept track of the last allocated MAC and assigned the next sequential MAC unless it was already in use.
This approach can cause issues in specific use cases where multi-clusters are merged into one, increasing the likelihood of MAC conflict.
Changing the algorithm to be random to ensure more robust MAC allocation for dynamic and distributed environments.
Special notes for your reviewer:
Release note: