-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
The Version Skew Policy does not mention aggregated apiservers #124655
Comments
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the 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. |
@kubernetes/sig-api-machinery-bugs |
@MikeSpreitzer if you agree, I suggest you transfer this to k/website. The Prow command for that is |
AIUI Kubernetes release versioning doesn't apply to any aggregated API servers, although some of the components you might run use library code that we release. You can implement an API server in any language and you don't need to have any Kubernetes code in your implementation. However, your aggregated API server should ideally to be compatible with every API server in your control plane at any point during an upgrade. We can still document more about compatibility than we do right now. |
wasn't this talked about recently @MikeSpreitzer ? #124533 (comment) |
I think the other issue #124533 has been transitioned to a docs issue. I will close this one in favor of the other one. Please re-open if I am mistaken. /close |
@seans3: Closing this issue. In response to this:
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-sigs/prow repository. |
What happened?
Someone opened #124533 saying
I think that is not what the version skew policy (https://kubernetes.io/releases/version-skew-policy/) is trying to say. I think that the guiding principle is that you must first upgrade the servers that store objects of a given API group and resource/kind, then upgrade the clients of those servers.
In particular, the existing version skew policy document explicitly discusses several kinds of components, but does not mention aggregated apiservers. I think that these should be explicitly mentioned.
What did you expect to happen?
Everybody agrees on what to expect.
How can we reproduce it (as minimally and precisely as possible)?
Read the cited doc and Issue.
Anything else we need to know?
Nope
Kubernetes version
All of them.
Cloud provider
OS version
N/A
Install tools
Container runtime (CRI) and version (if applicable)
Related plugins (CNI, CSI, ...) and versions (if applicable)
The text was updated successfully, but these errors were encountered: