Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1769012

Summary:	Missing openapi CRD definitions for oc explain to work
Product:	OpenShift Container Platform	Reporter:	Maciej Szulik <maszulik>
Component:	kube-controller-manager	Assignee:	Maciej Szulik <maszulik>
Status:	CLOSED ERRATA	QA Contact:	zhou ying <yinzhou>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	4.3.0	CC:	aos-bugs, mfojtik
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-01-23 11:11:03 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:

Description Maciej Szulik 2019-11-05 18:22:54 UTC

The following PR https://github.com/openshift/origin/pull/22696 introduced an e2e which is verifying that all the operators provide descriptive information as part of their schema which is then available through oc explain command. 
This was recently updated and brought back in https://github.com/openshift/origin/pull/24058. 

Your component has a few missing bits, see the commented out lines from the PR.

This should be fixed similarly to https://github.com/openshift/cluster-kube-controller-manager-operator/pull/302, 
iow. it should be using openshift/api's generated CRD yamls. 

Once done update origin's e2e test and uncomment the lines from your components.

Comment 1 Maciej Szulik 2019-11-05 18:47:21 UTC

Should be fixed with https://github.com/openshift/cluster-kube-controller-manager-operator/pull/302

Comment 3 zhou ying 2019-11-07 10:06:19 UTC

The issue has fixed:
[root@dhcp-140-138 ~]# oc version
Client Version: v4.3.0
Server Version: 4.3.0-0.nightly-2019-11-06-230519
Kubernetes Version: v1.16.2

[root@dhcp-140-138 ~]# oc explain kubecontrollermanagers
KIND: KubeControllerManager
VERSION: operator.openshift.io/v1

DESCRIPTION:
KubeControllerManager provides information to configure an operator to
manage kube-controller-manager.

FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec <Object> -required-

status <Object>

[root@dhcp-140-138 ~]# oc explain kubecontrollermanagers.kind
KIND: KubeControllerManager
VERSION: operator.openshift.io/v1

FIELD: kind <string>

DESCRIPTION:
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
[root@dhcp-140-138 ~]# oc explain kubecontrollermanagers.spec
KIND: KubeControllerManager
VERSION: operator.openshift.io/v1

RESOURCE: spec <Object>

DESCRIPTION:
<empty>

FIELDS:
failedRevisionLimit <integer>
failedRevisionLimit is the number of failed static pod installer revisions
to keep on disk and in the api -1 = unlimited, 0 or unset = 5 (default)

forceRedeploymentReason <string>
forceRedeploymentReason can be used to force the redeployment of the
operand by providing a unique string. This provides a mechanism to kick a
previously failed deployment and provide a reason why you think it will
work this time instead of failing again on the same config.

logLevel <string>
logLevel is an intent based logging for an overall component. It does not
give fine grained control, but it is a simple way to manage coarse grained
logging choices that operators have to interpret for their operands.

managementState <string>
managementState indicates whether and how the operator should manage the
component

observedConfig <>
observedConfig holds a sparse config that controller has observed from the
cluster state. It exists in spec because it is an input to the level for
the operator

operatorLogLevel <string>
operatorLogLevel is an intent based logging for the operator itself. It
does not give fine grained control, but it is a simple way to manage coarse
grained logging choices that operators have to interpret for themselves.

succeededRevisionLimit <integer>
succeededRevisionLimit is the number of successful static pod installer
revisions to keep on disk and in the api -1 = unlimited, 0 or unset = 5
(default)

unsupportedConfigOverrides <>
unsupportedConfigOverrides holds a sparse config that will override any
previously set options. It only needs to be the fields to override it will
end up overlaying in the following order: 1. hardcoded defaults 2.
observedConfig 3. unsupportedConfigOverrides

[root@dhcp-140-138 ~]# oc explain kubecontrollermanagers.spec.observedConfig
KIND: KubeControllerManager
VERSION: operator.openshift.io/v1

DESCRIPTION:
observedConfig holds a sparse config that controller has observed from the
cluster state. It exists in spec because it is an input to the level for
the operator

Comment 5 errata-xmlrpc 2020-01-23 11:11:03 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