Bug 1755383

Summary:	CVO blocks use of new Kube API features of 1.14+ in OpenShift manifests
Product:	OpenShift Container Platform	Reporter:	Stefan Schimanski <sttts>
Component:	Cluster Version Operator	Assignee:	Abhinav Dahiya <adahiya>
Status:	CLOSED ERRATA	QA Contact:	liujia <jiajliu>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	4.3.0	CC:	aos-bugs, calfonso, jokerman, mnewby, sdodson, xxia
Target Milestone:	---
Target Release:	4.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-05-13 21:25:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Comment 4 Abhinav Dahiya 2019-10-01 23:46:36 UTC

> There is a CRD builder that is not based on the dynamic client (prove me wrong, then this BZ is superfluous).

https://github.com/openshift/cluster-version-operator/blob/0725bd53c732c8e3a490d1080f03edbe7e579b3a/lib/resourcebuilder/register.go#L17 and
https://github.com/openshift/cluster-version-operator/blob/0725bd53c732c8e3a490d1080f03edbe7e579b3a/pkg/cvo/cvo.go#L530-L566

the CVO only registers the special builder/handler for CRDs v1beta1, that means any CRD v1 will be handled by the dynamic client handler.

The means the CVO will not wait for CRD v1 objects to be accepted, i.e CRs for that version will fail with not ready/ no api style errors, but that doesn't block anybody as it will be cosmetic errors that resolve eventually.

But we will work on updating the CVO to handle CRD v1 more natively for better error handling.

Comment 5 Maru Newby 2019-10-04 02:13:25 UTC

bump PR: https://github.com/openshift/cluster-version-operator/pull/249

Comment 10 Xingxing Xia 2019-10-23 03:28:01 UTC

Currently all crds use v1beta1 and all components' manifests use v1beta1 [1]:
$ oc get crds
NAME                                                        CREATED AT
alertmanagers.monitoring.coreos.com                         2019-10-23T01:45:06Z
apiservers.config.openshift.io                              2019-10-23T01:38:36Z
authentications.config.openshift.io                         2019-10-23T01:38:36Z
...
$ oc get crds -o yaml | grep "apiVersion: apiextensions.k8s.io.*"
- apiVersion: apiextensions.k8s.io/v1beta1
- apiVersion: apiextensions.k8s.io/v1beta1
- apiVersion: apiextensions.k8s.io/v1beta1
...

[1] E.g. https://github.com/openshift/cluster-kube-scheduler-operator/blob/master/manifests/0000_25_kube-scheduler-operator_01_config.crd.yaml#L1

If QE want to verify the bug once it is fixed, could you give some ideas how to verify? Is it enough to verify it by checking: all crds use v1, regression functional tests pass and upgrade tests pass?

Comment 12 liujia 2019-10-31 02:48:41 UTC

According to our qe and dev's disscussion at https://coreos.slack.com/archives/CB48XQ4KZ/p1571987371119300?thread_ts=1571981898.118700&cid=CB48XQ4KZ.

This bug needs not qe's verify work. So close the bug.

Comment 14 errata-xmlrpc 2020-05-13 21:25:10 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0062

Comment 15 Red Hat Bugzilla 2023-09-14 05:43:44 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days