-
Notifications
You must be signed in to change notification settings - Fork 53
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
helm: revert parts of CoreDNS Helm chart packaging #3366
Conversation
✅ Deploy Preview for constellation-docs canceled.
|
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.
we should probably add a TODO(v2.19) to the helm chart installation / add a ticket. but I think you have this under control @burgerdev
Note to reviewers: There are three commits,
Limiting the diff to the last one should be sufficient.
I'll add an AB ticket, thanks for the reminder. |
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.
While the upgrade test is still failing, the code itself LGTM
Interesting - failing upgrades were not even a symptom of the issue addressed here, and this branch is rebased on #3361. The failure is also during initial cluster setup at v2.17.0, which should be sufficiently tested by now. Let's see what the retry does. |
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.
Thanks for explaining this so thoroughly!
Coverage report
|
Context
We are trying to move CoreDNS from a cluster addon managed by
kubeadm
to a Helm chart managed alongside the Constellation microservices.After #3236, upgrading a cluster reverted CoreDNS to the version installed by
kubeadm
. This required #3353 as a workaround - the cluster pretends it does not have CoreDNS to fool kubeadm, details in that PR's description.This workaround had an unexpected consequence, though: kubeadm has a preflight check for CoreDNS, which now starts failing. Since this check is done in the upgrade-agent, which is part of the image, it does not benefit from the
--ignore
s added in #3353 and fails. Now thekubeadm upgrade
step is never executed, which makes us miss important migrations in the worst case.Proposed change(s)
Extend the migration to two upgrades.
Additional info
Checklist
[ ] GCP upgrade