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

OCPBUGS-41642: vendor: Update openshift/api to pick up the v4.17 capability set #1876

Open
wants to merge 1 commit into
base: release-4.17
Choose a base branch
from

Conversation

wking
Copy link
Member

@wking wking commented Sep 12, 2024

Catching up with openshift/api#2023, and a backport-ish of 45ab914729 (#1875), which may or may not land due to conflicts with the Kubernetes rebase. Generated with:

$ GOPROXY=direct go get github.com/openshift/api@release-4.17
$ go mod tidy
$ go mod vendor
$ git add -A go.* vendor

all using:

$ go version
go version go1.22.2 linux/amd64

where GOPROXY=direct avoids a caching delay:

I committed a new change (or released a new version) to a repository, why isn't it showing up when I run go get -u or go list -m --versions?

In order to improve our services' caching and serving latencies, new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue.

This addresses OCPBUGS-41111:

$ cat v4.17-basecap.yaml
---
apiVersion: v1
platform:
  gcp:
    foo: bar
capabilities:
  baselineCapabilitySet: v4.17
$ ./oc adm release extract --install-config v4.17-basecap.yaml --included --credentials-requests --from quay.io/openshift-release-dev/ocp-release:4.17.0-rc.1-x86_64 --to /tmp/test
error: unrecognized baselineCapabilitySet "v4.17"

because pkg/cli/admin/release/extract_tools.go uses the vendored openshift/api/config/v1 to unpack capabilities.

Catching up with [1], and a backport-ish of 45ab914729 (vendor: Update
openshift/api to pick up the v4.17 capability sets, 2024-09-11, openshift#1875),
which may or may not land due to conflicts with the Kubernetes rebase
[2].  Generated with:

  $ GOPROXY=direct go get github.com/openshift/api@release-4.17
  $ go mod tidy
  $ go mod vendor
  $ git add -A go.* vendor

all using:

  $ go version
  go version go1.22.2 linux/amd64

where GOPROXY=direct avoids a caching delay [3]:

  I committed a new change (or released a new version) to a
  repository, why isn't it showing up when I run go get -u or go list
  -m --versions?

  In order to improve our services' caching and serving latencies, new
  versions may not show up right away. If you want new code to be
  immediately available in the mirror, then first make sure there is a
  semantically versioned tag for this revision in the underlying
  source repository. Then explicitly request that version via go get
  module@version. The new version should be available within one
  minute. Note that if someone requested the version before the tag
  was pushed, it may take up to 30 minutes for the mirror's cache to
  expire and fresh data about the version to become available. If the
  version is still not available after 30 minutes, please file an
  issue.

This addresses [4]:

  $ cat v4.17-basecap.yaml
  ---
  apiVersion: v1
  platform:
    gcp:
      foo: bar
  capabilities:
    baselineCapabilitySet: v4.17
  $ ./oc adm release extract --install-config v4.17-basecap.yaml --included --credentials-requests --from quay.io/openshift-release-dev/ocp-release:4.17.0-rc.1-x86_64 --to /tmp/test
  error: unrecognized baselineCapabilitySet "v4.17"

because pkg/cli/admin/release/extract_tools.go uses the vendored
openshift/api/config/v1 to unpack capabilities.

[1]: openshift/api#2023
[2]: openshift#1875 (comment)
[3]: https://proxy.golang.org/
[4]: https://issues.redhat.com/browse/OCPBUGS-41111
@openshift-ci-robot
Copy link

@wking: An error was encountered adding this pull request to the external tracker bugs for bug OCPBUGS-41642 on the Jira server at https://issues.redhat.com/. No known errors were detected, please see the full error message for details.

Full error message. failed to add remote link: failed to add link: No Link Issue Permission for issue 'OCPBUGS-41642'.: request failed. Please analyze the request body for more details. Status code: 403:

Please contact an administrator to resolve this issue, then request a bug refresh with /jira refresh.

In response to this:

Catching up with openshift/api#2023, and a backport-ish of 45ab914729 (#1875), which may or may not land due to conflicts with the Kubernetes rebase. Generated with:

$ GOPROXY=direct go get github.com/openshift/api@release-4.17
$ go mod tidy
$ go mod vendor
$ git add -A go.* vendor

all using:

$ go version
go version go1.22.2 linux/amd64

where GOPROXY=direct avoids a caching delay:

I committed a new change (or released a new version) to a repository, why isn't it showing up when I run go get -u or go list -m --versions?

In order to improve our services' caching and serving latencies, new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue.

This addresses OCPBUGS-41111:

$ cat v4.17-basecap.yaml
---
apiVersion: v1
platform:
 gcp:
   foo: bar
capabilities:
 baselineCapabilitySet: v4.17
$ ./oc adm release extract --install-config v4.17-basecap.yaml --included --credentials-requests --from quay.io/openshift-release-dev/ocp-release:4.17.0-rc.1-x86_64 --to /tmp/test
error: unrecognized baselineCapabilitySet "v4.17"

because pkg/cli/admin/release/extract_tools.go uses the vendored openshift/api/config/v1 to unpack capabilities.

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
Copy link
Member Author

wking commented Sep 12, 2024

/Jira refresh

@openshift-ci-robot openshift-ci-robot added jira/severity-important Referenced Jira bug's severity is important for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. labels Sep 12, 2024
@openshift-ci-robot
Copy link

@wking: This pull request references Jira Issue OCPBUGS-41642, which is invalid:

  • expected dependent Jira Issue OCPBUGS-41111 to be in one of the following states: MODIFIED, ON_QA, VERIFIED, but it is POST instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

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.

@openshift-ci-robot openshift-ci-robot added the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Sep 12, 2024
Copy link
Contributor

openshift-ci bot commented Sep 13, 2024

@wking: all tests passed!

Full PR test history. Your PR dashboard.

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.

@jiajliu
Copy link

jiajliu commented Sep 13, 2024

pre-merge verify pass

/label qe-approved

@openshift-ci openshift-ci bot added the qe-approved Signifies that QE has signed off on this PR label Sep 13, 2024
@ardaguclu
Copy link
Member

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 13, 2024
Copy link
Contributor

openshift-ci bot commented Sep 13, 2024

[APPROVALNOTIFIER] This PR is APPROVED

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

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 13, 2024
@ingvagabund
Copy link
Member

/label backport-risk-assessed

@openshift-ci openshift-ci bot added the backport-risk-assessed Indicates a PR to a release branch has been evaluated and considered safe to accept. label Sep 13, 2024
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. backport-risk-assessed Indicates a PR to a release branch has been evaluated and considered safe to accept. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. jira/severity-important Referenced Jira bug's severity is important for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. qe-approved Signifies that QE has signed off on this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants