Skip to content

Update Operator CRD with UpgradeConstraintPolicy field #396

@m1kola

Description

@m1kola

Please read RFC for better formatting and full scope. The excerpt below is just to indicate the scope covered by this specific issue.

Need to update Operator CRD with UpgradeConstraintPolicy field per RFC:

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

Done

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions