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

Support semver ranges of versions to skip in the head of a channel #834

Merged

Conversation

ecordell
Copy link
Member

@ecordell ecordell commented Apr 30, 2019

Define a new annotation for CSVs:

olm.skipRange: <semver range>

where <semver range> has the semver range format supported by the semver lib we're using.

When searching catalogs for updates, if the head of a channel has this annotation and the currently installed operator has a version field that falls in the range, we will update to the latest entry in the channel.

The order of precedence is:

  1. Channel head in the source specified by sourceName on the subscription, if the other criteria for skipping are met
  2. The next operator that replaces the current one, in the source specified by sourceName
  3. Channel head in another source that is visible to the subscription, if the other criteria for skipping are met
  4. The next operator that replaces the current one in any source visible to the subscription

(haven't run the e2e tests locally yet b/c of my current internet connection)

@openshift-ci-robot openshift-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Apr 30, 2019
@ecordell ecordell force-pushed the semver-range branch 2 times, most recently from 25fa100 to e3ed0a2 Compare April 30, 2019 23:30
@dinhxuanvu
Copy link
Member

/retest

2 similar comments
@ecordell
Copy link
Member Author

ecordell commented May 1, 2019

/retest

@ecordell
Copy link
Member Author

ecordell commented May 1, 2019

/retest

the blang implementation supports range queries
@ecordell ecordell force-pushed the semver-range branch 5 times, most recently from ec0f6b9 to 943349a Compare May 1, 2019 15:19
explicitly states that a range of existing operators can update directly

this is to support z-stream releases for operators, where there is a
reasonable degree of confidence that it's safe to skip updates, and
where it is difficult to generate the graph ahead of time
Copy link
Member

@njhale njhale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really good. I just had a couple of questions.

)

const SkipPackageAnnotationKey = "olm.skipRange"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SkipRangeAnnotationKey?

@@ -207,6 +211,7 @@ func crd(key opregistry.APIKey) *v1beta1.CustomResourceDefinition {
}

func u(object runtime.Object) *unstructured.Unstructured {
fmt.Println(object)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

debug log?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops! just for tests though

}

for key, source := range q.sources {
bundle, err := source.GetReplacementBundleInPackageChannel(context.TODO(), bundleName, pkgName, channelName)
if err == nil {
bundle, err := q.findChannelHead(currentVersion, pkgName, channelName, source)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we not return the bundle if it's version matches currentVersion?

@@ -77,7 +79,7 @@ var (
},
Spec: v1alpha1.ClusterServiceVersionSpec{
Replaces: "",
Version: *semver.New("0.1.0"),
Version: version.OperatorVersion{semver.MustParse("0.1.0")},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we have a wrapper version.MustParse(...) function?

mainNamedStrategy := newNginxInstallStrategy(genName("dep-"), nil, nil)
mainCSV := newCSV(mainPackageStable, testNamespace, "", semver.MustParse("0.1.0-1556661347"), nil, nil, mainNamedStrategy)
updatedCSV := newCSV(updatedPackageStable, testNamespace, "", semver.MustParse("0.1.0-1556661832"), nil, nil, mainNamedStrategy)
updatedCSV.SetAnnotations(map[string]string{resolver.SkipPackageAnnotationKey: ">=0.1.0-1556661347 <0.1.0-1556661832"})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is 0.1.0-1556661832 exclusive to prevent it from being picked up as a replacement after it's installed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep!

}

for key, source := range q.sources {
bundle, err := source.GetReplacementBundleInPackageChannel(context.TODO(), bundleName, pkgName, channelName)
if err == nil {
bundle, err := q.findChannelHead(currentVersion, pkgName, channelName, source)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're iterating over a map, which is non-deterministic, if we have multiple catalogs with the same package/channel and CSVs at head with olm.skipRanges that include currentVersion, is it possible that we can have non-deterministic upgrades.

Could we also get false "upgrade available" detections if the range is inclusive of head?

Copy link
Member

@njhale njhale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label May 1, 2019
@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ecordell, njhale

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ecordell
Copy link
Member Author

ecordell commented May 1, 2019

/retest

1 similar comment
@ecordell
Copy link
Member Author

ecordell commented May 1, 2019

/retest

@openshift-merge-robot openshift-merge-robot merged commit bfc2f94 into operator-framework:master May 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants