Skip to content

Investigate rollback options for upgrade #420

Closed
@jamiehannaford

Description

In Lucas's upgrades PR a discussion span off about how we can ensure clusters are never left in a corrupted state after failed/borked upgrades. I think @pipejakob encapsulated it best:

It would be great if our upgrade plan had ... properties, so that kubeadm or any random component could crash at any time during the upgrade, and we would never leave the cluster in an unusable state where human intervention would be required to fix it

More context here: kubernetes/kubernetes#48899 (comment). We should look at if there's any easy way to do this.

/cc @luxas @timothysc

Metadata

Assignees

No one assigned

    Labels

    area/UXarea/upgradeslifecycle/rottenDenotes an issue or PR that has aged beyond stale and will be auto-closed.priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions