-
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
Version validation according Kubernetes Version Skew Policy #7011
Comments
the supported skew in kubeadm is documented here that said it does not strictly follow some more controversial areas, such as the kube-proxy / kubelet skew. |
Thanks for looking for duplicates; I have consolidated everything in #7010 and in this issue |
Q: Should the validation only consider the spec.version or should it also consider the current status? E.g. if we only validate the spec it's possible to bump the version two minor versions before the rollout is finished. |
Maybe yes, maybe no, also related here: #6651 . |
/triage accepted |
/help |
@fabriziopandini: GuidelinesPlease ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met. If this request no longer meets these requirements, the label can be removed 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/test-infra repository. |
/assign |
Do we have a clear idea what exactly we want to implement and where? |
+1 to nail down some details first |
Have not gone that much far, just started to explore the details . I'll sure discuss here or in slack before going for implementation. |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
/priority important-longterm |
The Cluster API project currently lacks enough active contributors to adequately respond to all issues and PRs. We mitigated the issue with machine set preflight checks and we highly reccommend users to turn them on. |
@fabriziopandini: 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/test-infra repository. |
User Story
As a operator I would like to ensure that creating/updating a Cluster/KubeadmControlPlane/MachineDeployment/MachineSet/Machine does not violate the [Kubernetes Version Skew Policy] for staying in supported upgrade paths and not break running applications.
Detailed Description
This issue proposes to add additional validation against the [Kubernetes Version Skew Policy].
Assuming version v1.X is the desired kubernetes version:
To-be-discussed:
Cluster.spec.topology.version
?Anything else you would like to add:
There is already version validation at the ClusterClass based clusters (via
.spec.topology.version
). xrefKubeadm also does validation against the Kubernetes Version Skew Policy, but this may not map to the current documentation at [Kubernetes Version Skew Policy].
/kind feature
The text was updated successfully, but these errors were encountered: