Proposal fast ipam #460
Proposal fast ipam #460
Conversation
ivelichkovich
force-pushed
the
proposal-fast-ipam
branch
from
97e23cb to
6bf218a
Compare
ivelichkovich
force-pushed
the
proposal-fast-ipam
branch
from
6bf218a to
2be13db
Compare
| ### Non-Goals | ||
|
|
||
| - Migrate all users to this new mode | ||
|
|
There was a problem hiding this comment.
Potentially we can add here "integrate reconciliation controller and the new controller" as a non-goal -- that can be left as a follow on if it adds too much overhead. I'm ok with starting with a brand new controller for this process.
There was a problem hiding this comment.
yes, I was actually thinking about adding this as a non-goal but we may want to do it in the future (with changes to the existing controller) so I left it as is for now but I can add it
|
|
||
| Another design is that the whereabouts daemonset that runs the install-cni script could be used to have a startup and | ||
| shutdown hook which would handle the assignment of nodes to a node slice. This would require locking for the `NodeSlicePools` | ||
| on Node join. The reason to use the controller over this design is because the reconciliation pattern reduces the likelyhood for bugs (like leaked IPs) |
|
One thing I'm kind of thinking about is that the reconciler has this "audit style reconciliation" that runs on a timed fashion. I'm wondering if we might introduce resource contention with it with the fast style allocation since it won't be using the leases. Just thinking out loud |
Are you referring to the gocron running within the existing reconciler controller? That one doesn't use leases at all as far as I can tell, it calls allocation.IterateForDeallocation directly. |
So! That being the case... we don't need to worry about it. I think that might just be an existing issue, so, I will look into that, thanks for taking a peek. |
|
|
||
| - Migrate all users to this new mode | ||
|
|
||
| <hr> |
There was a problem hiding this comment.
I think we're good to go on this design! Let's just add a section for next steps, may I suggest
## Phases
Initial phase:
[x] Fast ranges base functionality
Feature parity phase:
[ ] Range start, range-end function
[ ] Live changes to range (from regular to fast)
[ ] Multiple ranges
Optimization phase:
[ ] Dynamic range slice rebalancing
Definitely feel free to add / remove / edit these, just to get a placeholdre, thanks Igor!
There was a problem hiding this comment.
awesome thanks for the help! Let me just add that nice diagram as well from the maintainers call and then we should be good to go!
There was a problem hiding this comment.
woops I thought you committed this in already, just pushed the suggestions
Pull Request Test Coverage Report for Build 9023285561Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
What this PR does / why we need it:
proposal for fast IPAM through node slicing. Code PR: #458
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer (optional):