Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor legacy upgrade constraint semantics behind an interface #397

Closed
m1kola opened this issue Sep 5, 2023 · 0 comments · Fixed by #450
Closed

Refactor legacy upgrade constraint semantics behind an interface #397

m1kola opened this issue Sep 5, 2023 · 0 comments · Fixed by #450
Assignees
Milestone

Comments

@m1kola
Copy link
Member

m1kola commented Sep 5, 2023

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

We need to

Solver

The solver needs to be able to switch between upgrade constraint semantics based on rules defined above (see Fig 1).

Note that no matter the positions of ForceSemverUpgradeConstraints feature gate and value of .spec.upgradeConstraintPolicy we still need to apply Operator’s other constraints. This means that .spec.channel and .spec.version need to be taken into account during the resolution process, if these fields were set:

  • If the .spec.version field specifies a version or range, resolution must choose from a version that falls with that version or range
  • If the .spec.channel field specifies a channel, resolution must choose from a version that is a member of that channel

Refactoring of existing support of legacy semantics

In preparation of introducing of semver we need to:

  • Define an interface common for all the semantics
  • Refactor existing code which provides support of legacy semantics to match the interface

The idea is that there will be a function with roughly the following signature:

type Successors func(currentBundle string) []string

Where currentBundle uniquely identifies the currently installed bundle and the return value is a slice uniquely identifying possible successors.
For the legacy semantics possible successors will be bundles according to the replaces/skips/skipRange.

Reporting resolution issues must also happen as described in the RFC:

In case of errors during the resolution - issues must be reported via status update of the Operator. This applies to all semantics and all positions of the feature gate.

Operator is expected to set or update the condition of type Resolved to False with Reason set to ResolutionFailed and provide a meaningful error message.

conditions, metav1.Condition{
	Type:           	operatorsv1alpha1.TypeResolved,
	Status:         	metav1.ConditionFalse,
	Reason:         	operatorsv1alpha1.ReasonResolutionFailed,
	Message:        	message,
	ObservedGeneration: generation,
}
@m1kola m1kola changed the title Update solver to enable switching between semver and legacy upgrade constraint semantics Refactor legacy upgrade constraint semantics behind an interface Sep 7, 2023
@joelanford joelanford added this to the v0.6.0 milestone Sep 14, 2023
@m1kola m1kola self-assigned this Oct 3, 2023
@dtfranz dtfranz modified the milestones: v0.6.0, v0.7.0 Oct 3, 2023
@github-project-automation github-project-automation bot moved this to Done in OLM v1 Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants