Skip to content

Commit

Permalink
Merge pull request openshift#297 from markmc/upgrade-downgrade-expect…
Browse files Browse the repository at this point in the history
…ations

Template: add specific guidance in upgrade/downgrade section
  • Loading branch information
openshift-merge-robot authored Sep 10, 2020
2 parents 553d963 + 2b74aac commit bc89180
Showing 1 changed file with 28 additions and 0 deletions.
28 changes: 28 additions & 0 deletions guidelines/enhancement_template.md
Original file line number Diff line number Diff line change
Expand Up @@ -216,6 +216,34 @@ enhancement:
- What changes (in invocations, configurations, API use, etc.) is an existing
cluster required to make on upgrade in order to make use of the enhancement?

Upgrade expectations:
- Each component should remain available for user requests and
workloads during upgrades. Any exception to this should be
identified and discussed here.
- Micro version upgrades - users should be able to skip forward versions within a
minor release stream without being required to pass through intermediate
versions - i.e. `x.y.N->x.y.N+2` should work without requiring `x.y.N->x.y.N+1`
as an intermediate step.
- Minor version upgrades - you only need to support `x.N->x.N+1` upgrade
steps. So, for example, it is acceptable to require a user running 4.3 to
upgrade to 4.5 with a `4.3->4.4` step followed by a `4.4->4.5` step.
- While an upgrade is in progress, new component versions should
continue to operate correctly in concert with older component
versions (aka "version skew"). For example, if a node is down, and
an operator is rolling out a daemonset, the old and new daemonset
pods must continue to work correctly even while the cluster remains
in this partially upgraded state for some time.

Downgrade expectations:
- If an `N->N+1` upgrade fails mid-way through, or if the `N+1` cluster is
misbehaving, it should be possible for the user to rollback to `N`. It is
acceptable to require some documented manual steps in order to fully restore
the downgraded cluster to its previous state. Examples of acceptable steps
include:
- Deleting any CVO-managed resources added by the new version. The
CVO does not currently delete resources that no longer exist in
the target version.

### Version Skew Strategy

How will the component handle version skew with other components?
Expand Down

0 comments on commit bc89180

Please sign in to comment.