OPRUN-3588: Update openshift/api to pick up OLM V1 v4.18 capability sets

[LalatenduMohanty]

Catching up with [1]. Generated with:

$ go get github.com/openshift/api@a2817b89f7e0989016967055a142d5e88bed18de
$ go get github.com/openshift/client-go@923091dd2b1a3d6fe75a06cc4f45972a3ddf84c2
$ go get github.com/openshift/library-go@0064ad7bd060b9fd52f7840972c1d3e72186d0f0
$ go mod tidy
$ go mod vendor
$ git add -A go.* vendor

$ go version
go version go1.22.5 linux/amd64

[1] openshift/api/pull/2066

[LalatenduMohanty]

/hold

[LalatenduMohanty]

/hold cancel

[LalatenduMohanty]

I could not change the RateLimitingInterface here as library-go still uses old version of API and it wont accept new change

[grokspawn]

Hey @LalatenduMohanty , any concern that this update includes a bump to k8s 1.31?

[wking]

..., any concern that this update includes a bump to k8s 1.31?

4.18 uses Kube 1.31, e.g. 4.18.0-ec.3:

Components
Kubectl 1.31.1
Kubernetes upgraded from 1.31.1 to 1.31.2
Kubernetes Tests upgraded from 1.30.0 to 1.31.1
...

and openshift/kubernetes#2092, so should be fine for us to use Kube 1.31 clients, right? I guess that gives us a very brief window where an incoming 4.18 CVO is using 1.31 clients before the Kube API server has had time to update to 1.31, but 🤷, the CVO doesn't do fancy things with cutting edge Kube API types during that window, and hopefully 1.31 client code is backwards-compatible with 1.30 Kube API servers to bridge that kind of skew.

[wking]

/jira refresh

[openshift-ci-robot]

@wking: No Jira issue is referenced in the title of this pull request.
To reference a jira issue, add 'XYZ-NNN:' to the title of this pull request and request another refresh with /jira refresh.

Details

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[wking]

Drop the pre-colon space to make the bots happy

/retitle OPRUN-3588: Update openshift/api to pick up OLM V1 v4.18 capability sets

[openshift-ci-robot]

@LalatenduMohanty: This pull request references OPRUN-3588 which is a valid jira issue.

Details

In response to this:

Catching up with [1]. Generated with:

$ go get github.com/openshift/api@a2817b89f7e0989016967055a142d5e88bed18de
$ go get github.com/openshift/client-go@923091dd2b1a3d6fe75a06cc4f45972a3ddf84c2
$ go get github.com/openshift/library-go@0064ad7bd060b9fd52f7840972c1d3e72186d0f0
$ go mod tidy
$ go mod vendor
$ git add -A go.* vendor

$ go version
go version go1.22.5 linux/amd64

[1] openshift/api/pull/2066

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[wking]

This pull looks good to me, although CI is still running, and I'm waiting that out before adding the lgtm label. Talking through some of the context:

• These docs walk through the new-capability onboarding process.
• OPRUN-3588: Add OperatorLifecycleManagerV1 cluster version capability api#2066 added the OperatorLifecycleManagerV1 capability to the API repo, and is what's getting pulled in by the vendor bump here.
• OPRUN-3588: OLM: add OperatorLifecycleManagerV1 capability to olms CRD api#2097 is up in the queue to get an capability.openshift.io/name: OperatorLifecycleManagerV1 annotation on the olms.operator.openshift.io CRD.
• OPRUN-3588: Add OLMv1 capability annotation to manifests cluster-olm-operator#78 is up to add that annotation to the other manifests related to the capability. We've audited an earlier CI run from that pull, and it had test-cases like [sig-olmv1] OLMv1 operator installation should install a cluster extension [Suite:openshift/conformance/parallel] failing, as expected when the capability is not enabled but the test suite expects it to be available.
• NO-ISSUE: Add Capability and FeatureGate checks to OLMv1 tests origin#29283 is up to improve the test-suite's "is it enabled?" detection, but it's currently hard to exercise this, because the feature is also gated by the NewOLM feature gate on the v1 CRD, and that is still not in the default feature set, and Cluster Bot doesn't seem to like the no-capabilities,techpreview combination.
• There will be follow-up work to add configv1.Default to NewOLM's enableIn, but no pull-request up for that yet.
• TechPreview CI on this pull passing is promising for the wheels not immediately falling off in the window between this pull request merging and NO-ISSUE: Add Capability and FeatureGate checks to OLMv1 tests origin#29283 and OPRUN-3588: Add OLMv1 capability annotation to manifests cluster-olm-operator#78 merging. But this pull request merging is a one-way valve that's really hard to walk back (more on the CVO vs. dropping capabilities from the set of known capabilities in OTA-1223: config/v1/types_cluster_version: Drop enum from ClusterVersion status capabilities api#1624), so on top of waiting for CVO maintainers to add the lgtm label, I'm adding a hold so the OLM folks can decide when they're confident enough to merge it:

/hold for OLM to lift when they're ready for this to merge.

[wking]

e2e-agnostic-operator failures look like infra, and unrelated to this pull request, so retest that:

/test e2e-agnostic-operator

$ curl -s https://storage.googleapis.com/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1108/pull-ci-openshift-cluster-version-operator-master-e2e-agnostic-operator/1856432680753696768/build-log.txt | grep 'Install attempt\|failed to create cluster\|Installer exit with code'
Install attempt 1 of 3
level=error msg=failed to fetch Cluster: failed to generate asset "Cluster": failed to create cluster: failed to provision control-plane machines within 15m0s: client rate limiter Wait returned an error: context deadline exceeded
Installer exit with code 4
Install attempt 2 of 3
level=error msg=failed to fetch Cluster: failed to generate asset "Cluster": failed to create cluster: failed provisioning resources after infrastructure ready: failed to finish creating gallery image version 418.94.20241009: GET https://management.azure.com/subscriptions/d38f1e38-4bed-438e-b227-833f997adf6a/providers/Microsoft.Compute/locations/eastus/capsOperations/6c0764d1-d60d-4fd3-aa18-cc8a856a794b
Installer exit with code 4
Install attempt 3 of 3
level=error msg=failed to fetch Cluster: failed to generate asset "Cluster": failed to create cluster: failed provisioning resources after infrastructure ready: failed to finish creating gallery image version 418.94.20241009: GET https://management.azure.com/subscriptions/d38f1e38-4bed-438e-b227-833f997adf6a/providers/Microsoft.Compute/locations/eastus/capsOperations/ae6c5228-cebd-4952-858b-ec73ed4a54ef
Installer exit with code 4

[LalatenduMohanty]

ci/prow/e2e-agnostic-ovn-upgrade-out-of-change

This failure does not seem related to the PR. @wking what are we going to do for hypershift test failures?

[petr-muller]

My bet is that the out-of-change failure is related to the PR but is actually expected and we'll need to override.

It's a update timeout:

INFO[2024-11-12T22:03:41Z] Running step e2e-agnostic-ovn-upgrade-out-of-change-openshift-e2e-test. 
{"component":"entrypoint","file":"sigs.k8s.io/prow/pkg/entrypoint/run.go:169","func":"sigs.k8s.io/prow/pkg/entrypoint.Options.ExecuteProcess","level":"error","msg":"Process did not finish before 4h0m0s timeout","severity":"error","time":"2024-11-13T00:23:59Z"} 

It is not possible to update from the version that knows the new capability to the version without that capability.

[LalatenduMohanty]

Looks like hypershift tests have passed now.

@wking @petr-muller can we get a lgtm on this PR and I will remove the hold when we are ready

[petr-muller]

I will remove the hold when we are ready

Can we get this tested? (by OLM or OTA QE?). Capability PRs are hard to revert when problematic. We block CVO merges on QE approval (or explicit decision that pre-merge testing is not necessary or desirable for some reason).

[wking]

Yup, once we confirm that's the only issue with the upgrade-out-of-change job, we:

/override ci/prow/e2e-agnostic-ovn-upgrade-out-of-change

we could get better visibility with openshift/api#1624, but I haven't been able to get that prioritized.

/lgtm

[openshift-ci]

@wking: Overrode contexts on behalf of wking: ci/prow/e2e-agnostic-ovn-upgrade-out-of-change

Details

In response to this:

Yup, once we confirm that's the only issue with the upgrade-out-of-change job, we:

/override ci/prow/e2e-agnostic-ovn-upgrade-out-of-change

we could get better visibility with openshift/api#1624, but I haven't been able to get that prioritized.

/lgtm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-ci]

@LalatenduMohanty: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: LalatenduMohanty, wking

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [wking]

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

[joelanford]

Manually adding qe-approved. We have performed pre-merge testing that gives high confidence this PR is ready to merge. See https://issues.redhat.com/browse/OPRUN-3588?focusedId=26070118&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-26070118

[joelanford]

/label qe-approved

[joelanford]

/hold cancel

[openshift-ci-robot]

@LalatenduMohanty: This pull request references OPRUN-3588 which is a valid jira issue.

Details

In response to this:

Catching up with [1]. Generated with:

$ go get github.com/openshift/api@a2817b89f7e0989016967055a142d5e88bed18de
$ go get github.com/openshift/client-go@923091dd2b1a3d6fe75a06cc4f45972a3ddf84c2
$ go get github.com/openshift/library-go@0064ad7bd060b9fd52f7840972c1d3e72186d0f0
$ go mod tidy
$ go mod vendor
$ git add -A go.* vendor

$ go version
go version go1.22.5 linux/amd64

[1] openshift/api/pull/2066

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: cluster-version-operator
This PR has been included in build cluster-version-operator-container-v4.19.0-202411140108.p0.gb0eddfe.assembly.stream.el9.
All builds following this will include this PR.