Add pick_addresses option for explicit IP candidate selection#674
Add pick_addresses option for explicit IP candidate selection#674DeamonMV wants to merge 1 commit intok8snetworkplumbingwg:masterfrom
pick_addresses option for explicit IP candidate selection#674Conversation
In some environments, only a specific subset of IPs within a subnet are available for allocation — due to external infrastructure constraints, policy grouping, or operational lifecycle (e.g., IPs rotating in and out of service). The existing range_start/range_end mechanism requires contiguous ranges, which cannot express arbitrary sets of eligible addresses. The new `pick_addresses` field in RangeConfiguration allows users to specify an explicit list of candidate IPs. When provided, allocation selects from this list (in order) instead of iterating the full range, while still honoring CIDR bounds, exclude ranges, and existing reservations. Also fixes IPManagementKubernetesUpdate to preserve OmitRanges and PickAddresses when reconstructing range configuration for node slicing, where these fields were previously silently dropped.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a significant enhancement to IP address allocation by allowing explicit selection of IP candidates. This new functionality provides greater flexibility for environments with specific IP management requirements that cannot be met by simple contiguous ranges. Additionally, it includes a crucial fix to ensure that all range configuration parameters, including the new pick addresses and existing omit ranges, are correctly maintained during node slicing operations. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces the pick_addresses option to the IP address allocation process, allowing users to specify an explicit list of candidate IPs for allocation. This addresses the limitation of the existing range-based allocation mechanism, which requires contiguous ranges. The changes include modifications to the IterateForAssignment function to incorporate the pickAddr parameter and corresponding logic to select IPs from the provided list. Additionally, the IPManagementKubernetesUpdate function is updated to preserve OmitRanges and PickAddresses during range configuration reconstruction. The pull request also includes new unit tests to validate the functionality of the pick_addresses option.
| // No valid IPs in pick list; return regular assignment error | ||
| return net.IP{}, reserveList, AssignmentError{firstIP, lastIP, ipnet, excludeRanges} |
There was a problem hiding this comment.
The error message returned when no valid IPs are found in the pickAddr list could be more informative. Consider including details about why the IPs were invalid (e.g., out of range, reserved, excluded) to aid in debugging.
Also, consider returning a wrapped error that includes the original AssignmentError for better context.
| // No valid IPs in pick list; return regular assignment error | |
| return net.IP{}, reserveList, AssignmentError{firstIP, lastIP, ipnet, excludeRanges} | |
| return net.IP{}, reserveList, fmt.Errorf("no valid IP addresses found in pick list: %w", AssignmentError{firstIP, lastIP, ipnet, excludeRanges}) |
| Expect(err).To(HaveOccurred()) | ||
| Expect(err.Error()).To(ContainSubstring("Could not allocate IP in range")) |
There was a problem hiding this comment.
The error message assertion ContainSubstring("Could not allocate IP in range") is too generic. It would be better to assert against a more specific error message that includes details about the pickAddr list and why the allocation failed. This will make the test more robust and easier to debug.
1 participant
What this PR does / why we need it:
In some environments, only a specific subset of IPs within a subnet are available for allocation — due to external infrastructure constraints, policy grouping, or operational lifecycle (e.g., IPs rotating in and out of service). The existing range_start/range_end mechanism requires contiguous ranges, which cannot express arbitrary sets of eligible addresses.
The new
pick_addressesfield in RangeConfiguration allows users to specify an explicit list of candidate IPs. When provided, allocation selects from this list (in order) instead of iterating the full range, while still honoring CIDR bounds, exclude ranges, and existing reservations.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Also fixes IPManagementKubernetesUpdate to preserve OmitRanges and PickAddresses when reconstructing range configuration for node slicing, where these fields were previously silently dropped.
Special notes for your reviewer (optional):