-
Notifications
You must be signed in to change notification settings - Fork 204
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
feat: Implement Migration Controller #1689
feat: Implement Migration Controller #1689
Conversation
Hi @rschalo. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
checkpointing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: njtran, rschalo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
11b8901
into
kubernetes-sigs:release-v1.0.x
Fixes #N/A
Description
To facilitate the v1beta1 to v1 migration, Karpenter introduced conversion webhooks. These webhooks were introduced in patch versions to v0.33.x-v0.37.x along with the 1.0 release. As a result, users are able to upgrade to 1.0 with their existing v1beta1 resources. These resources would be automatically converted by the webhooks so users could upgrade without downtime. Users would then migrate the resources they’re applying (e.g. through pipelines or GitOps solutions) to v1 before the conversion webhooks are dropped at v1.1.
There is a problem when users upgrade to v1.1. Users change the storage version on their CRDs to v1 as part of the v1.0 upgrade, however this only affects newly created resources and resources which have had writes performed against them. It is possible that a user could upgrade to v1.1 while resources are still stored as v1beta1, potentially resulting in data loss.
This PR implements two controllers to perform the write against Karpenter resources and when all resources have been updated, update
status.StoredVersions
for Karpenter resources to be just v1.How was this change tested?
Local testing and unit tests.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.