OCPBUGS-33983: vendor: Update openshift/api to pick up zz_generated.crd-manifests #1045

wking · 2024-04-30T18:29:33Z

Catching up with the YAML getting shifted into a subdirectory (openshift/api#1814). I followed the new docs to create pkg/dependencymagnet, and then:

$ emacs pkg/featuregates/featuregates.go pkg/featuregates/featurechangestopper_test.go # configv1.FeatureGateUpgradeStatus -> features.FeatureGateUpgradeStatus
$ go get github.com/openshift/api@master github.com/openshift/library-go@master
$ go mod tidy
$ go mod vendor
$ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator)
$ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet go.* vendor

all using:

$ go version
go version go1.22.2 linux/amd64

A few points on the invocation:

I usually use go get -u ..., e.g. in a98232f (OTA-917: pkg/customsignaturestore: Implement signatureStores customization #994), but in this case, that would pull in k8s.io/[email protected], and we want to stick with 0.29 until our release-4.16 branch stops following this development branch.

I'm explicitly bumping library-go, because if I don't, builds fail on:

Building github.com/openshift/cluster-version-operator (v1.0.0-1203-g258de3f7-dirty)
# github.com/openshift/library-go/pkg/manifest
vendor/github.com/openshift/library-go/pkg/manifest/manifest.go:32:35: undefined: configv1.FeatureSets
# github.com/openshift/cluster-version-operator/pkg/featuregates
pkg/featuregates/featuregates.go:92:32: undefined: configv1.FeatureGateUpgradeStatus
pkg/featuregates/featuregates.go:97:33: undefined: configv1.FeatureGateUpgradeStatus

If I had been able to use -u, library-go would have automatically floated to the tip commit anyway. But either way, I still needed to make manual changes to keep up with NO-JIRA: move featuregate definitions to a new package api#1821 moving to the new openshift/api/features package.

openshift-ci-robot · 2024-04-30T18:29:37Z

@wking: This pull request references OTA-1282 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.

In response to this:

Catching up with the YAML getting shifted into a subdirectory (openshift/api#1814). I followed the new docs to create pkg/dependencymagnet, and then:

$ go get -u github.com/openshift/api@master
$ go mod tidy
$ go mod vendor
$ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator)
$ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet go.* vendor

all using:

$ go version
go version go1.22.2 linux/amd64

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 · 2024-04-30T19:53:53Z

@wking: This pull request references OTA-1282 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.

In response to this:

Catching up with the YAML getting shifted into a subdirectory (openshift/api#1814). I followed the new docs to create pkg/dependencymagnet, and then:

$ go get github.com/openshift/api@master
$ go mod tidy
$ go mod vendor
$ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator)
$ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet go.* vendor

all using:

$ go version
go version go1.22.2 linux/amd64

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 · 2024-04-30T20:29:55Z

@wking: This pull request references OTA-1282 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.

In response to this:

Catching up with the YAML getting shifted into a subdirectory (openshift/api#1814). I followed the new docs to create pkg/dependencymagnet, and then:
$ emacs pkg/featuregates/featuregates.go pkg/featuregates/featurechangestopper_test.go # configv1.FeatureGateUpgradeStatus -> features.FeatureGateUpgradeStatus
$ go get github.com/openshift/api@master github.com/openshift/library-go@master
$ go mod tidy
$ go mod vendor
$ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator)
$ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet go.* vendor
all using:
$ go version
go version go1.22.2 linux/amd64
A few points on the invocation:
I usually use go get -u ..., e.g. in a98232f (OTA-917: pkg/customsignaturestore: Implement signatureStores customization #994), but in this case, that would pull in k8s.io/[email protected], and we want to stick with 0.29 until our release-4.16 branch stops following this development branch.
I'm explicitly bumping library-go, because if I don't, builds fail on:
Building github.com/openshift/cluster-version-operator (v1.0.0-1203-g258de3f7-dirty)
# github.com/openshift/library-go/pkg/manifest
vendor/github.com/openshift/library-go/pkg/manifest/manifest.go:32:35: undefined: configv1.FeatureSets
# github.com/openshift/cluster-version-operator/pkg/featuregates
pkg/featuregates/featuregates.go:92:32: undefined: configv1.FeatureGateUpgradeStatus
pkg/featuregates/featuregates.go:97:33: undefined: configv1.FeatureGateUpgradeStatus
If I had been able to use -u, library-go would have automatically floated to the tip commit anyway. But either way, I still needed to make manual changes to keep up with NO-JIRA: move featuregate definitions to a new package api#1821 moving to the new openshift/api/features package.

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 · 2024-05-01T03:27:34Z

OSProvisioningTimedOut is just Azure being slow, and it's orthogonal to my change:

/retest-required

PratikMahajan · 2024-05-01T19:38:26Z

LGTM

petr-muller

/retest-required

wking · 2024-05-02T17:24:49Z

Still pointing at last-Tuesday's run?

/retest-required

wking · 2024-05-08T16:36:14Z

/retest-required

wking · 2024-05-10T05:23:52Z

/retest-required

shellyyang1989 · 2024-05-10T09:59:48Z

/retest

petr-muller · 2024-05-13T12:29:47Z

/retest-required

petr-muller · 2024-05-15T13:54:03Z

/retest

petr-muller · 2024-05-16T09:20:21Z

OK now it starts to be weirdly persistent: we get OSProvisioningTimedOut consistently over a week, across three different jobs. search.ci shows shows hits only on this PR. But I really do not see how could a PR in our repository cause this 🤔

I had two hypotheses but I had to rule them out:

I thought that maybe somehow our ci-op-xxxxx id somehow poisoned Azure (weird stuck leaked resource, whatever) but ci-op-xxxxxx id here changed over time
I thought that maybe CVO jobs have some weird configuration, but jobs on Lala's OCPBUGS-24700: Add support for Custom Certificate Authorities for custom signature stores #1030 ran fine yesterday.

wking · 2024-05-20T17:18:38Z

I moved the Jira ticket to a bug, now that we'll need to backport this to 4.16 (to set the ground for any other 4.16 bugs that need an API-repo vendor bump).

/retitle OCPBUGS-33983: vendor: Update openshift/api to pick up zz_generated.crd-manifests

openshift-ci-robot · 2024-05-20T17:18:48Z

@wking: This pull request references Jira Issue OCPBUGS-33983, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target version (4.17.0) matches configured target version for branch (4.17.0)
bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

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

In response to this:

Catching up with the YAML getting shifted into a subdirectory (openshift/api#1814). I followed the new docs to create pkg/dependencymagnet, and then:
$ emacs pkg/featuregates/featuregates.go pkg/featuregates/featurechangestopper_test.go # configv1.FeatureGateUpgradeStatus -> features.FeatureGateUpgradeStatus
$ go get github.com/openshift/api@master github.com/openshift/library-go@master
$ go mod tidy
$ go mod vendor
$ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator)
$ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet go.* vendor
all using:
$ go version
go version go1.22.2 linux/amd64
A few points on the invocation:
I usually use go get -u ..., e.g. in a98232f (OTA-917: pkg/customsignaturestore: Implement signatureStores customization #994), but in this case, that would pull in k8s.io/[email protected], and we want to stick with 0.29 until our release-4.16 branch stops following this development branch.
I'm explicitly bumping library-go, because if I don't, builds fail on:
Building github.com/openshift/cluster-version-operator (v1.0.0-1203-g258de3f7-dirty)
# github.com/openshift/library-go/pkg/manifest
vendor/github.com/openshift/library-go/pkg/manifest/manifest.go:32:35: undefined: configv1.FeatureSets
# github.com/openshift/cluster-version-operator/pkg/featuregates
pkg/featuregates/featuregates.go:92:32: undefined: configv1.FeatureGateUpgradeStatus
pkg/featuregates/featuregates.go:97:33: undefined: configv1.FeatureGateUpgradeStatus
If I had been able to use -u, library-go would have automatically floated to the tip commit anyway. But either way, I still needed to make manual changes to keep up with NO-JIRA: move featuregate definitions to a new package api#1821 moving to the new openshift/api/features package.

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.

petr-muller · 2024-06-22T16:52:58Z

/test /e2e-agnostic-ovn e2e-agnostic-ovn-upgrade-out-of-change e2e-agnostic-operator

petr-muller · 2024-06-22T17:06:20Z

/test e2e-agnostic-ovn

eranco74 · 2024-07-10T06:31:56Z

@eranco74: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

periodic-ci-openshift-release-master-ci-4.17-e2e-aws-ovn-techpreview

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/fcf5a130-3e70-11ef-8814-9902ddae661f-0

NM I see the job passed here

eranco74 · 2024-07-10T06:32:04Z

/lgtm

petr-muller · 2024-07-10T11:08:21Z

/test lint e2e-hypershift-conformance

lint failure is an infra flake but the e2e-agnostic-operator looks legit:

{  Unable to read vendor/github.com/openshift/api/config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversion-Default.crd.yaml: open vendor/github.com/openshift/api/config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversion-Default.crd.yaml: no such file or directory
exit status 1
{"component":"entrypoint","error":"wrapped process failed: exit status 1","file":"sigs.k8s.io/prow/pkg/entrypoint/run.go:84","func":"sigs.k8s.io/prow/pkg/entrypoint.Options.internalRun","level":"error","msg":"Error executing test process","severity":"error","time":"2024-07-09T21:48:29Z"}
error: failed to execute wrapped command: exit status 1
}

hack/test-prerequisites.go

Catching up with the YAML getting shifted into a subdirectory [1]. I followed the new docs from [2] to create pkg/dependencymagnet, and then: $ emacs pkg/featuregates/featuregates.go pkg/featuregates/featurechangestopper_test.go # configv1.FeatureGateUpgradeStatus -> features.FeatureGateUpgradeStatus $ go get github.com/openshift/api@master github.com/openshift/library-go@master $ go mod tidy $ go mod vendor $ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator) $ sed -i 's/$clusterversion\|clusteroperator$/\1s/' hack/test-prerequisites.go $ git checkout a90cec9 -- pkg/payload/render.go # Eran Cohen's DevPreviewNoUpgrade exclusion $ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet go.* vendor all using: $ go version go version go1.22.2 linux/amd64 A few points on the invocation: * I usually use 'go get -u ...', e.g. a98232f (vendor: Bump openshift/api to pick up signatureStores, 2023-12-04, openshift#994), but in this case, that would pull in k8s.io/[email protected], and we want to stick with 0.29 until our release-4.16 branch stops following this development branch. * I'm explicitly bumping library-go, because if I don't, builds fail on [3]: Building github.com/openshift/cluster-version-operator (v1.0.0-1203-g258de3f7-dirty) # github.com/openshift/library-go/pkg/manifest vendor/github.com/openshift/library-go/pkg/manifest/manifest.go:32:35: undefined: configv1.FeatureSets # github.com/openshift/cluster-version-operator/pkg/featuregates pkg/featuregates/featuregates.go:92:32: undefined: configv1.FeatureGateUpgradeStatus pkg/featuregates/featuregates.go:97:33: undefined: configv1.FeatureGateUpgradeStatus If I had been able to use -u, library-go would have automatically floated to the tip commit anyway. But either way, I still needed to make manual changes to keep up with [4] moving to the new openshift/api/features package. And I want [5]. * The DevPreviewNoUpgrade exclusion avoids bootstrap failures like [6]: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808/artifacts/e2e-aws-ovn-techpreview/ipi-install-install/artifacts/log-bundle-20240709194524.tar | tar -xOz log-bundle-20240709194524/bootstrap/journals/bootkube.log | grep 'are not consistent so results would be unpredictable depending on apply order' | tail -n4 Jul 09 19:45:15 ip-10-0-155-191 kube-apiserver-render[74584]: F0709 19:45:15.447834 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:15 ip-10-0-155-191 bootkube.sh[74561]: F0709 19:45:15.447834 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:27 ip-10-0-155-191 kube-apiserver-render[75368]: F0709 19:45:27.669093 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:27 ip-10-0-155-191 bootkube.sh[75345]: F0709 19:45:27.669093 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values as the kube-apiserver-render command worries about the CVO having rendered two ClusterVersion CRDs: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808/artifacts/e2e-aws-ovn-techpreview/ipi-install-install/artifacts/log-bundle-20240709194524.tar | tar -tvz | grep 'cvo-bootstrap/.*cluster-version-operator.*crd' -rw-r--r-- core/core 42129 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml -rw-r--r-- core/core 39010 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml -rw-r--r-- core/core 7628 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusteroperators.crd.yaml [1]: openshift/api#1814 [2]: openshift/api@06baaa4#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R211 [3]: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-images/1785396933666279424#1:build-log.txt%3A74-79 [4]: openshift/api#1821 [5]: openshift/library-go#1759 [6]: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808

petr-muller · 2024-07-10T17:38:58Z

/lgtm
/label no-qe

openshift-ci · 2024-07-10T17:39:52Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: eranco74, petr-muller, 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:

~~OWNERS~~ [petr-muller,wking]

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

openshift-ci-robot · 2024-07-10T18:38:38Z

/retest-required

Remaining retests: 0 against base HEAD 44257e1 and 2 for PR HEAD e9762c6 in total

wking · 2024-07-10T20:19:42Z

Bunch of failed test-cases in the HyperShift run, and I don't have a good handle on what happened there. Overall pass rate for that job is not great, but maybe we'll get lucky with a retest:

/retest-required

wking · 2024-07-10T20:31:12Z

It looks like the failing test-cases were concentrated around images and builds. And also like they might be getting fixed via openshift/hypershift#4349. I'd be ok with an /override ..., but we've gone this long without a vendor bump; I expect we can wait until the HyperShift revert merges and kick another retest here then, if the current retest fails the same way.

wking · 2024-07-11T14:48:04Z

openshift/hypershift#4351 may have fixed the HyperShift CI:

/retest-required

openshift-ci · 2024-07-11T16:51:33Z

@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.

openshift-ci-robot · 2024-07-11T16:55:13Z

@wking: Jira Issue OCPBUGS-33983: Some pull requests linked via external trackers have merged:

openshift/cluster-version-operator#1051

The following pull requests linked via external trackers have not merged:

openshift/cluster-version-operator#1062 is closed

These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with /jira refresh.

Jira Issue OCPBUGS-33983 has not been moved to the MODIFIED state.

In response to this:

Catching up with the YAML getting shifted into a subdirectory (openshift/api#1814). I followed the new docs to create pkg/dependencymagnet, and then:
$ emacs pkg/featuregates/featuregates.go pkg/featuregates/featurechangestopper_test.go # configv1.FeatureGateUpgradeStatus -> features.FeatureGateUpgradeStatus
$ go get github.com/openshift/api@master github.com/openshift/library-go@master
$ go mod tidy
$ go mod vendor
$ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator)
$ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet go.* vendor
all using:
$ go version
go version go1.22.2 linux/amd64
A few points on the invocation:
I usually use go get -u ..., e.g. in a98232f (OTA-917: pkg/customsignaturestore: Implement signatureStores customization #994), but in this case, that would pull in k8s.io/[email protected], and we want to stick with 0.29 until our release-4.16 branch stops following this development branch.
I'm explicitly bumping library-go, because if I don't, builds fail on:
Building github.com/openshift/cluster-version-operator (v1.0.0-1203-g258de3f7-dirty)
# github.com/openshift/library-go/pkg/manifest
vendor/github.com/openshift/library-go/pkg/manifest/manifest.go:32:35: undefined: configv1.FeatureSets
# github.com/openshift/cluster-version-operator/pkg/featuregates
pkg/featuregates/featuregates.go:92:32: undefined: configv1.FeatureGateUpgradeStatus
pkg/featuregates/featuregates.go:97:33: undefined: configv1.FeatureGateUpgradeStatus
If I had been able to use -u, library-go would have automatically floated to the tip commit anyway. But either way, I still needed to make manual changes to keep up with NO-JIRA: move featuregate definitions to a new package api#1821 moving to the new openshift/api/features package.

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 · 2024-07-11T19:13:57Z

/jira refresh

openshift-ci-robot · 2024-07-11T19:14:04Z

@wking: Jira Issue OCPBUGS-33983: All pull requests linked via external trackers have merged:

Jira Issue OCPBUGS-33983 has been moved to the MODIFIED state.

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-bot · 2024-07-11T19:21:40Z

[ART PR BUILD NOTIFIER]

This PR has been included in build cluster-version-operator-container-v4.17.0-202407111842.p0.gdf4cb12.assembly.stream.el9 for distgit cluster-version-operator.
All builds following this will include this PR.

@master

Like e9762c6 (vendor: Update openshift/api to pick up zz_generated.crd-manifests, 2024-04-30, openshift#1045), except I pulled release-4.16 branches. Catching up with the YAML getting shifted into a subdirectory [1]. I followed the new docs from [2] to create pkg/dependencymagnet, and then: $ emacs pkg/featuregates/featuregates.go pkg/featuregates/featurechangestopper_test.go # configv1.FeatureGateUpgradeStatus -> features.FeatureGateUpgradeStatus $ go get github.com/openshift/[email protected] github.com/openshift/library-go@190fec8c3f09de1290c0dcaa25556b4515d65fc6 # different from e9762c6's @master $ go mod tidy $ go mod vendor $ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator) $ sed -i 's/$clusterversion\|clusteroperator$/\1s/' hack/test-prerequisites.go $ git checkout a90cec9 -- pkg/payload/render.go # Eran Cohen's DevPreviewNoUpgrade exclusion $ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet pkg/featuregates go.* vendor all using: $ go version go version go1.22.2 linux/amd64 A few points on the invocation: * I usually use 'go get -u ...', e.g. a98232f (vendor: Bump openshift/api to pick up signatureStores, 2023-12-04, openshift#994), but in this case, that would pull in k8s.io/[email protected], and we want to stick with 0.29 until our release-4.16 branch stops following this development branch. * I'm explicitly bumping library-go, because if I don't, builds fail on [3]: Building github.com/openshift/cluster-version-operator (v1.0.0-1203-g258de3f7-dirty) # github.com/openshift/library-go/pkg/manifest vendor/github.com/openshift/library-go/pkg/manifest/manifest.go:32:35: undefined: configv1.FeatureSets # github.com/openshift/cluster-version-operator/pkg/featuregates pkg/featuregates/featuregates.go:92:32: undefined: configv1.FeatureGateUpgradeStatus pkg/featuregates/featuregates.go:97:33: undefined: configv1.FeatureGateUpgradeStatus If I had been able to use -u, library-go would have automatically floated to the tip commit anyway. But either way, I still needed to make manual changes to keep up with [4] moving to the new openshift/api/features package. * And I want [5], but for some reason: $ go get github.com/openshift/[email protected] github.com/openshift/[email protected] was getting me the older v0.0.0-20240517135010-e93e442c2b18. I'm not clear on why. But requesting the library-go commit I wanted by commit-hash instead of by branch-name got me the CustomNoUpgrade fix. * The DevPreviewNoUpgrade exclusion avoids bootstrap failures like [6]: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808/artifacts/e2e-aws-ovn-techpreview/ipi-install-install/artifacts/log-bundle-20240709194524.tar | tar -xOz log-bundle-20240709194524/bootstrap/journals/bootkube.log | grep 'are not consistent so results would be unpredictable depending on apply order' | tail -n4 Jul 09 19:45:15 ip-10-0-155-191 kube-apiserver-render[74584]: F0709 19:45:15.447834 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:15 ip-10-0-155-191 bootkube.sh[74561]: F0709 19:45:15.447834 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_cluster versions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:27 ip-10-0-155-191 kube-apiserver-render[75368]: F0709 19:45:27.669093 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_ 01_clusterversions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:27 ip-10-0-155-191 bootkube.sh[75345]: F0709 19:45:27.669093 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_cluster versions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values as the kube-apiserver-render command worries about the CVO having rendered two ClusterVersion CRDs: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808/artifacts/e2e-aws-ovn-techpre view/ipi-install-install/artifacts/log-bundle-20240709194524.tar | tar -tvz | grep 'cvo-bootstrap/.*cluster-version-operator.*crd' -rw-r--r-- core/core 42129 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml -rw-r--r-- core/core 39010 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml -rw-r--r-- core/core 7628 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusteroperators.crd.yaml [1]: openshift/api#1814 [2]: openshift/api@06baaa4#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R211 [3]: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-images/1785396933666279424#1:build-log.txt%3A74-79 [4]: openshift/api#1821 [5]: openshift/library-go#1759 Backported to 4.16 in openshift/library-go#1762 [6]: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808

@master

Like e9762c6 (vendor: Update openshift/api to pick up zz_generated.crd-manifests, 2024-04-30, openshift#1045), except I pulled release-4.16 branches. Catching up with the YAML getting shifted into a subdirectory [1]. I followed the new docs from [2] to create pkg/dependencymagnet, and then: $ emacs pkg/featuregates/featuregates.go pkg/featuregates/featurechangestopper_test.go # configv1.FeatureGateUpgradeStatus -> features.FeatureGateUpgradeStatus $ go get github.com/openshift/[email protected] github.com/openshift/library-go@190fec8c3f09de1290c0dcaa25556b4515d65fc6 # different from e9762c6's @master $ go mod tidy $ go mod vendor $ sed -i 's|config/v1/0000_00_cluster-version-operator|config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator|g' $(git grep -l 0000_00_cluster-version-operator) $ sed -i 's/$clusterversion\|clusteroperator$/\1s/' hack/test-prerequisites.go $ git checkout a90cec9 -- pkg/payload/render.go # Eran Cohen's DevPreviewNoUpgrade exclusion $ git add -A Dockerfile* hack/test-prerequisites.go pkg/dependencymagnet pkg/featuregates go.* vendor all using: $ go version go version go1.22.2 linux/amd64 A few points on the invocation: * I usually use 'go get -u ...', e.g. a98232f (vendor: Bump openshift/api to pick up signatureStores, 2023-12-04, openshift#994), but in this case, that would pull in k8s.io/[email protected], and we want to stick with 0.29 until our release-4.16 branch stops following this development branch. * I'm explicitly bumping library-go, because if I don't, builds fail on [3]: Building github.com/openshift/cluster-version-operator (v1.0.0-1203-g258de3f7-dirty) # github.com/openshift/library-go/pkg/manifest vendor/github.com/openshift/library-go/pkg/manifest/manifest.go:32:35: undefined: configv1.FeatureSets # github.com/openshift/cluster-version-operator/pkg/featuregates pkg/featuregates/featuregates.go:92:32: undefined: configv1.FeatureGateUpgradeStatus pkg/featuregates/featuregates.go:97:33: undefined: configv1.FeatureGateUpgradeStatus If I had been able to use -u, library-go would have automatically floated to the tip commit anyway. But either way, I still needed to make manual changes to keep up with [4] moving to the new openshift/api/features package. * And I want [5], but for some reason: $ go get github.com/openshift/[email protected] github.com/openshift/[email protected] was getting me the older v0.0.0-20240517135010-e93e442c2b18. I'm not clear on why. But requesting the library-go commit I wanted by commit-hash instead of by branch-name got me the CustomNoUpgrade fix. * The DevPreviewNoUpgrade exclusion avoids bootstrap failures like [6]: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808/artifacts/e2e-aws-ovn-techpreview/ipi-install-install/artifacts/log-bundle-20240709194524.tar | tar -xOz log-bundle-20240709194524/bootstrap/journals/bootkube.log | grep 'are not consistent so results would be unpredictable depending on apply order' | tail -n4 Jul 09 19:45:15 ip-10-0-155-191 kube-apiserver-render[74584]: F0709 19:45:15.447834 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:15 ip-10-0-155-191 bootkube.sh[74561]: F0709 19:45:15.447834 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_cluster versions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:27 ip-10-0-155-191 kube-apiserver-render[75368]: F0709 19:45:27.669093 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_ 01_clusterversions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values Jul 09 19:45:27 ip-10-0-155-191 bootkube.sh[75345]: F0709 19:45:27.669093 1 render.go:75] --rendered-manifest-files, are not consistent so results would be unpredictable depending on apply order: "/assets/manifests/0000_00_cluster-version-operator_01_cluster versions-DevPreviewNoUpgrade.crd.yaml" and "/assets/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml" both set CustomResourceDefinition.apiextensions.k8s.io/clusterversions.config.openshift.io in ns/, but have different values as the kube-apiserver-render command worries about the CVO having rendered two ClusterVersion CRDs: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808/artifacts/e2e-aws-ovn-techpre view/ipi-install-install/artifacts/log-bundle-20240709194524.tar | tar -tvz | grep 'cvo-bootstrap/.*cluster-version-operator.*crd' -rw-r--r-- core/core 42129 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml -rw-r--r-- core/core 39010 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml -rw-r--r-- core/core 7628 2024-07-09 12:45 log-bundle-20240709194524/rendered-assets/openshift/cvo-bootstrap/manifests/0000_00_cluster-version-operator_01_clusteroperators.crd.yaml [1]: openshift/api#1814 [2]: openshift/api@06baaa4#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R211 [3]: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-images/1785396933666279424#1:build-log.txt%3A74-79 [4]: openshift/api#1821 [5]: openshift/library-go#1759 Backported to 4.16 in openshift/library-go#1762 [6]: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1045/pull-ci-openshift-cluster-version-operator-master-e2e-aws-ovn-techpreview/1810753819311607808

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Apr 30, 2024

openshift-ci bot requested review from DavidHurta and LalatenduMohanty April 30, 2024 18:31

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 30, 2024

wking force-pushed the api-bump-move-crds branch from caa8cfe to 07f2e87 Compare April 30, 2024 19:52

wking force-pushed the api-bump-move-crds branch 2 times, most recently from 4f7c3d1 to f995620 Compare April 30, 2024 20:21

wking force-pushed the api-bump-move-crds branch from f995620 to 855432b Compare April 30, 2024 20:34

petr-muller approved these changes May 2, 2024

View reviewed changes

petr-muller approved these changes May 8, 2024

View reviewed changes

openshift-ci bot assigned petr-muller May 8, 2024

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label May 8, 2024

openshift-ci bot changed the title ~~OTA-1282: vendor: Update openshift/api to pick up zz_generated.crd-manifests~~ OCPBUGS-33983: vendor: Update openshift/api to pick up zz_generated.crd-manifests May 20, 2024

openshift-ci-robot added the jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. label May 20, 2024

openshift-ci bot assigned eranco74 Jul 10, 2024

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jul 10, 2024

eranco74 mentioned this pull request Jul 10, 2024

METAL-1053: Remove baremetal dependency on MachineAPI capability #1064

Closed

This was referenced Jul 10, 2024

no-jira: bump(github.com/openshift/api,github.com/openshift/library-go)=release-4.17 #1067

Closed

WRKLDS-1380: bump(github.com/openshift/api): DeploymentConfig: drop capability fro… #1066

Open

petr-muller reviewed Jul 10, 2024

View reviewed changes

hack/test-prerequisites.go Outdated Show resolved Hide resolved

hack/test-prerequisites.go Outdated Show resolved Hide resolved

wking force-pushed the api-bump-move-crds branch from dbe139c to e9762c6 Compare July 10, 2024 16:02

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Jul 10, 2024

openshift-ci bot added no-qe Allows PRs to merge without qe-approved label lgtm Indicates that a PR is ready to be merged. labels Jul 10, 2024

openshift-merge-bot bot merged commit df4cb12 into openshift:master Jul 11, 2024
12 checks passed

wking deleted the api-bump-move-crds branch July 11, 2024 18:57

wking mentioned this pull request Jul 11, 2024

OCPBUGS-36898: vendor: Update openshift/api to pick up zz_generated.crd-manifests #1069

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OCPBUGS-33983: vendor: Update openshift/api to pick up zz_generated.crd-manifests #1045

OCPBUGS-33983: vendor: Update openshift/api to pick up zz_generated.crd-manifests #1045

wking commented Apr 30, 2024 •

edited

Loading

openshift-ci-robot commented Apr 30, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Apr 30, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Apr 30, 2024 •

edited by openshift-ci bot

Loading

wking commented May 1, 2024

PratikMahajan commented May 1, 2024

petr-muller left a comment

wking commented May 2, 2024

wking commented May 8, 2024

wking commented May 10, 2024

shellyyang1989 commented May 10, 2024

petr-muller commented May 13, 2024

petr-muller commented May 15, 2024

petr-muller commented May 16, 2024

wking commented May 20, 2024

openshift-ci-robot commented May 20, 2024

petr-muller commented Jun 22, 2024

petr-muller commented Jun 22, 2024

eranco74 commented Jul 10, 2024

eranco74 commented Jul 10, 2024

petr-muller commented Jul 10, 2024

petr-muller commented Jul 10, 2024

openshift-ci bot commented Jul 10, 2024

openshift-ci-robot commented Jul 10, 2024

wking commented Jul 10, 2024

wking commented Jul 10, 2024

wking commented Jul 11, 2024

openshift-ci bot commented Jul 11, 2024

openshift-ci-robot commented Jul 11, 2024

wking commented Jul 11, 2024

openshift-ci-robot commented Jul 11, 2024

openshift-bot commented Jul 11, 2024

OCPBUGS-33983: vendor: Update openshift/api to pick up zz_generated.crd-manifests #1045

OCPBUGS-33983: vendor: Update openshift/api to pick up zz_generated.crd-manifests #1045

Conversation

wking commented Apr 30, 2024 • edited Loading

openshift-ci-robot commented Apr 30, 2024 • edited by openshift-ci bot Loading

openshift-ci-robot commented Apr 30, 2024 • edited by openshift-ci bot Loading

openshift-ci-robot commented Apr 30, 2024 • edited by openshift-ci bot Loading

wking commented May 1, 2024

PratikMahajan commented May 1, 2024

petr-muller left a comment

Choose a reason for hiding this comment

wking commented May 2, 2024

wking commented May 8, 2024

wking commented May 10, 2024

shellyyang1989 commented May 10, 2024

petr-muller commented May 13, 2024

petr-muller commented May 15, 2024

petr-muller commented May 16, 2024

wking commented May 20, 2024

openshift-ci-robot commented May 20, 2024

petr-muller commented Jun 22, 2024

petr-muller commented Jun 22, 2024

eranco74 commented Jul 10, 2024

eranco74 commented Jul 10, 2024

petr-muller commented Jul 10, 2024

petr-muller commented Jul 10, 2024

openshift-ci bot commented Jul 10, 2024

openshift-ci-robot commented Jul 10, 2024

wking commented Jul 10, 2024

wking commented Jul 10, 2024

wking commented Jul 11, 2024

openshift-ci bot commented Jul 11, 2024

openshift-ci-robot commented Jul 11, 2024

wking commented Jul 11, 2024

openshift-ci-robot commented Jul 11, 2024

openshift-bot commented Jul 11, 2024

wking commented Apr 30, 2024 •

edited

Loading

openshift-ci-robot commented Apr 30, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Apr 30, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Apr 30, 2024 •

edited by openshift-ci bot

Loading