-
Story
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
Future Sustainability
-
False
-
-
False
-
1
-
None
-
None
-
INKEY$ (OPRUN 243)
Description:
Update to the Operator CRD to include the `UpgradeConstraintPolicy` field as proposed in the RFC.
Background:
The RFC proposes the following
Operator’s `spec` must be extended. Suggested changes to OperatorSpec:
//+kubebuilder:validation:enum:=Enforce;Ignore //+kubebuilder:default:=Enforce //+kubebuilder:Optional // // Defines the policy for how to handle upgrade constraints. UpgradeConstraintPolicy string `json:"upgradeConstraintPolicy,omitempty"`Possible values:
const ( // The operator will only upgrade if the new version satisfies // the upgrade constraints set by the package author. UpgradeConstraintPolicyEnforce = "Enforce" // Unsafe option which allows an operator to be // upgraded or downgraded to any available version of the package and // ignore the upgrade path designed by package authors. // This assumes that users independently verify the outcome of the changes. // Use with caution as this can lead to unknown and potentially // disastrous results such as data loss. UpgradeConstraintPolicyIgnore = "Ignore" ) When .spec.upgradeConstraintPolicy is set to Ignore we do not apply upgrade constraints. This means an Operator can be transitioned to any available version of the package (even one older than the currently installed one). Note that, if set, other constraints on Operator still apply (e.g. .spec.version and .spec.channel).When .spec.upgradeConstraintPolicy is set to Enforce we use either semver or legacy semantics depending on the position of the ForceSemverUpgradeConstraints feature gate.
Upgrade constraint application process is depicted on Fig 1.
- is depended on by
-
OPRUN-3070 [upstream] Documentation for semver upgrade edge constraints support
-
- Closed
-
- links to