-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kubernetes: bundle, not vendor, cpuset code #207
Conversation
Import `cpuset` package and copy in the tree up until we can vendor `k8s.io/utils` compatible with version 1.28. This is another step to get rid of the `k8s.io/kubernetes` dependency. Signed-off-by: Francesco Romani <[email protected]>
trivial move + fix to the imported, and more up to date, cpuset code. This will allow us to be more forward compatible when we will switch again to the vendored `k8s.io/utils` code. Signed-off-by: Francesco Romani <[email protected]>
remove the now-unneeded `cpuset` vendored dep. Signed-off-by: Francesco Romani <[email protected]>
final step and the engine that is propelling all this work: #206 (depends on this one, WIP) |
What is the justification of getting rid of the k8s deps? |
The main driver is to be able to get rid of |
So why not just wait for 1.28 and it will remove automatically because |
that's also an option. It's up to us (maintaining the project) to decide if we want to have this bundling (expected to be stable and low-effort) for a while or just wait for 1.28. |
/lgtm |
in order to remove all dependencies on
k8s.io/kubernetes
, bundle (= copy/paste in the tree) the cpuset code instead of vendoring. We can just revert back to vendoring when we can update tok8s.io/utils
compatible to 1.28, so worst case when we bump to kube 1.28.