-
Notifications
You must be signed in to change notification settings - Fork 716
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
RFE: backup manifest dir gets wiped after upgrade #489
Comments
Thanks for filing the issue! It was on my list to follow up. @luxas -- I think you wrote this code. What do you think about leaving the old manifests there so that users can see what changed. It also enables a (dangerous) rollback path. |
If you think the command should "leak" directories for the user -- feel free to change. |
some users may want to do a comparison of the changes between versions but not think to copy off the existing config files prior to running the upgrade addresses kubernetes/kubeadm#489
@luxas @jbeda I submitted kubernetes/kubernetes#57116 as an attempt to address the concern here. If y'all think it's better to go the route of adding verbiage to the upgrade docs, I'm happy to go that route instead. |
@jipperinbham Thanks! I think more documentation would be better 👍 |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/assign @liztio |
The manifests are a pretty insignificant amount of data. @timothysc mentioned it would also be useful to store the old kubeadm-config as a file in the backupdir We'd probably store the etcd backup in the same directory? related #651 |
We should definitely outline best practices as part of an upgrade, but as we mentioned on the call rollback will become unsupportable for HA with the current methods and I think kubeadm overstepped here. |
Sorry for the lack of feedback here, I think some of the original thoughts behind this issue revolved around providing the user some way of previewing the changes prior to actually running the upgrade. Something I've enjoyed when using kops is the delta it provides when running I know being able to provide some sort of preview delta is a much bigger change for kubeadm. If a current goal is around outlining best practices and providing good feedback to the user, then it may or may not be something worth pursuing. |
@jipperinbham it's a considerable change for UX, but the technical parts are already there to support what you're talking about. |
FWIW; we kinda already support this "preview" feature with |
So the following makes a lot of sense to me:
|
I'm not going to have time to get to 2 or 3 before I leave for holiday. here's where the manifests are deleted |
Automatic merge from submit-queue (batch tested with PRs 63865, 57849, 63932, 63930, 63936). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Implement `kubeadm init diff` **What this PR does / why we need it**: Some users want to see the changes `kubeadm` woulda apply before actually running `kubeadm upgrade apply`. This shows the changes that will be made to the static pod manifests before applying them. This is a narrower case than `kubeadm upgrade apply --dry-run`, which specifically focuses on the static pod manifests. **Which issue(s) this PR fixes**: Part of [kubeadm/489](kubernetes/kubeadm#489 (comment)) **Special notes for your reviewer**: **Release note**: ```release-note adds the `kubeadm upgrade diff` command to show how static pod manifests will be changed by an upgrade. ```
going to resume this now that we have more time until freeze |
Automatic merge from submit-queue (batch tested with PRs 62460, 64480, 63774, 64540, 64337). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Save kubeadm manifest backup directories **What this PR does / why we need it**: Kubeadm will now preserves previous manifests after `kubeadm upgrade apply`. Previously these files would be deleted after the upgrade succeeded **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: Fixes # [kubeadm/489](kubernetes/kubeadm#489) **Special notes for your reviewer**: **Release note**: ```release-note kubeadm now preserves previous manifests after upgrades ```
What keywords did you search in kubeadm issues before filing this one?
BUG REPORT
Versions
kubeadm version (use
kubeadm version
): 1.8.0Environment:
kubectl version
): 1.7.6What happened?
While watching TGIK, @jbeda ran
sudo kubeadm upgrade apply v1.8.0
and the upgrade ran successfully but the previous manifests in/etc/kubernetes/tmp
were deleted.What you expected to happen?
The general comments were the previous manifests should have been kept around even with a successful upgrade.
How to reproduce it (as minimally and precisely as possible)?
sudo kubeadm upgrade apply v1.8.0
ls -alh /etc/kubernetes/tmp
Anything else we need to know?
This looks to be the expected behavior per https://github.com/kubernetes/kubernetes/blob/73d1b38604d6f39ec77a94f0f411a46c765d1c4f/cmd/kubeadm/app/phases/upgrade/staticpods.go#L172 so the question is whether the current behavior needs to be altered.
The text was updated successfully, but these errors were encountered: