diff options
| author | Tim Allclair <tallclair@google.com> | 2018-06-21 15:40:41 -0700 |
|---|---|---|
| committer | Tim Allclair <tallclair@google.com> | 2018-06-21 16:49:44 -0700 |
| commit | 2a3e21fe6b9a82604792bd4d292377b01979ac35 (patch) | |
| tree | fff20e1b3c13c678bd87edc14afa5f938f460839 /keps/sig-node | |
| parent | a185256c070c7fc52eb82ad9caab56512ad2f7c1 (diff) | |
Revisit upgrade section, spec is immutable
Diffstat (limited to 'keps/sig-node')
| -rw-r--r-- | keps/sig-node/0014-runtime-class.md | 21 |
1 files changed, 10 insertions, 11 deletions
diff --git a/keps/sig-node/0014-runtime-class.md b/keps/sig-node/0014-runtime-class.md index 6c2a9461..e5b9f1cf 100644 --- a/keps/sig-node/0014-runtime-class.md +++ b/keps/sig-node/0014-runtime-class.md @@ -263,17 +263,15 @@ message RunPodSandboxRequest { ### Versioning, Updates, and Rollouts -_Axiom: Rerunning a pod on a different node in the same cluster with the same RuntimeClassName should -not change its behavior._ +Getting upgrades and rollouts right is a very nuanced and complicated problem. For the initial alpha +implementation, we will kick the can down the road by making the `RuntimeClassSpec` **immutable**, +thereby requiring changes to be pushed as a newly named RuntimeClass instance. This means that pods +must be updated to reference the new RuntimeClass, and comes with the advantage of native support +for rolling updates through the same mechanisms as any other application update. -This means that if a runtime is updated in a fully backwards-compatible way, then the RuntimeClass -does not _need_ to change. It also means that if the updated runtime breaks backwards compatibility, -then it **MUST** be renamed. RuntimeClass does not provide a predefined versioning or naming scheme, -so versioned upgrades are left to the cluster operator to handle. - -Since breaking runtime changes require a new RuntimeClass definition, it means that pods must be -updated to reference the new RuntimeClass. This comes with the advantage of native support for -rolling updates through the same mechanisms as any other application update. +This conservative approach is preferred since it's much easier to relax constraints in a backwards +compatible way than tighten them. We should revisit this decision prior to graduating RuntimeClass +to beta. ### Implementation Details @@ -327,7 +325,8 @@ Beta: - Major runtimes support RuntimeClass - RuntimeClasses are configured in the E2E environment with test coverage of a non-legacy RuntimeClass -- TBD +- The update & upgrade story is revisited, and a longer-term approach is implemented as necessary. +- Additional requirements TBD ## Implementation History |