-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
✨Simplify alternative control-plane implementation #10198
Comments
/triage needs-discussion While I see value in reusing experiences across projects and possibly having some more help in KCP which is traditionally on the shoulders of one or two maintainers, I'm a little bit concerned about two angles of this discussion:
e.g. a fix like #10154 (the last KCP fix I recently reviewed) will probably require two minors to go through deprecation, while today we can easily include this in a patch release. Similarly, due to guarantee on public methods signature, in most cases back-port won't be possible anymore. That's a lot to give up for a piece of code so critical in CAPI, unless we find a way to preserve flexibility and speed.
I don't have a clear idea of what is "general-pourpose" and what is not; this makes it difficult for me to visualize how we should refactor the code to achieve the goal. If I stick just to the example of "etcd member management" is something that spans all across the codebase (scale up, down, upgrade, remediation, conditions etc). This would imply a major refactor across the entire KCP codebase. That means that we probably need a more in-depth analysis and an incremental plan that allows us to manage the risk and impacts comfortably. Let's wait for opinions from other core maintainers as well |
/priority backlog |
This issue is currently awaiting triage. CAPI contributors will take a look as soon as possible, apply one of the Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
What would you like to be added (User Story)?
As a developer I’d like a better separation of concerns for control-plane provider implementation and have an ability to reuse general purpose logic located in the kubeadm provider implementation.
Detailed Description
Currently provided approaches for cluster bootstrap and control plane management (kubeadm) include non-generic elements, and alternative control-plane providers (CAPBRKE2) have to copy parts of the original implementation.
An example of this is etcd member management, required for correct scaling-down operations with control-plane nodes while maintaining cluster overall health. It is marked as optional in the original proposal, but absent etcd membership management/or leader removal causes etcd to fail (downstream issue with details.)
Anything else you would like to add?
Example of the logic which provider code may want to reuse include:
Label(s) to be applied
/kind feature
/area bootstrap
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.
The text was updated successfully, but these errors were encountered: