Bug 1688638 - Some CRDs of config.openshift.io apiversion with the 'oc explain` command will return empty info
Summary: Some CRDs of config.openshift.io apiversion with the 'oc explain` command wil...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Master
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.1.0
Assignee: Maciej Szulik
QA Contact: zhou ying
URL:
Whiteboard:
: 1698644 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-14 06:54 UTC by zhou ying
Modified: 2019-06-04 10:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 10:45:49 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:45:56 UTC

Description zhou ying 2019-03-14 06:54:27 UTC
Description of problem:
Some CRD of config.openshift.io like: clusteroperators/clusterversions/dnses/networks/registries, when use the 'oc explain' command, will return nothing

Version-Release number of selected component (if applicable):
Client Version: v4.0.22
Server Version: v1.12.4+4836bc9
Payload version:4.0.0-0.nightly-2019-03-13-233958


How reproducible:
Always

Steps to Reproduce:
1. Use the command `oc explain` with the CRD of config.openshift.io like: clusteroperators/clusterversions/dnses/networks/registries

Actual results:
1. The DESCRIPTION of output always empty and no FIELDS:
oc explain registries
KIND:     Registry
VERSION:  config.openshift.io/v1

DESCRIPTION:
     <empty>

Expected results:
1. Have detail info for the CRD of config.openshift.io

Additional info:
Other CRD like: projects, works well.
oc explain projects --api-version="config.openshift.io/v1"
KIND:     Project
VERSION:  config.openshift.io/v1

DESCRIPTION:
     <empty>

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/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/api-conventions.md#types-kinds

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

   spec        <Object> -required-
     spec holds user settable values for configuration

   status        <map[string]>
     status holds observed values from the cluster. They may not be overridden.

Comment 1 Maciej Szulik 2019-03-14 15:28:59 UTC
We at least need the following PRs to land:
- https://github.com/openshift/cluster-openshift-apiserver-operator/pull/158
- https://github.com/openshift/cluster-kube-apiserver-operator/pull/273
- https://github.com/openshift/cluster-config-operator/pull/27

Maybe more is needed, but I need to land those first.

Comment 2 Maciej Szulik 2019-03-27 14:31:27 UTC
I think we're in a good state now, let's move to QA for verification.

Comment 3 zhou ying 2019-03-28 05:05:39 UTC
Confirmed with latest version :
[root@dhcp-140-138 roottest]# oc version --short
Client Version: v4.0.22
Server Version: v1.12.4+87e98f4
Payload: 4.0.0-0.nightly-2019-03-27-213938

The CRD :clusteroperator and clusterversion still don't have any information.

Comment 4 zhou ying 2019-03-28 05:06:08 UTC
[root@dhcp-140-138 roottest]# oc explain clusteroperators --api-version="config.openshift.io/v1"
KIND:     ClusterOperator
VERSION:  config.openshift.io/v1

DESCRIPTION:
     <empty>
[root@dhcp-140-138 roottest]# oc explain clusterversions --api-version="config.openshift.io/v1"
KIND:     ClusterVersion
VERSION:  config.openshift.io/v1

DESCRIPTION:
     <empty>

Comment 5 Hongan Li 2019-04-11 09:14:24 UTC
Tested with latest 4.0.0-0.nightly-2019-04-10-182914 and `oc explain` always returning "error: Couldn't find resource for <some resources>", see examples below:

$ oc explain console --api-version=config.openshift.io/v1
error: Couldn't find resource for "config.openshift.io/v1, Kind=Console"

$ oc explain IngressController
error: Couldn't find resource for "operator.openshift.io/v1, Kind=IngressController"
$ oc explain IngressController --api-version=operator.openshift.io/v1
error: Couldn't find resource for "operator.openshift.io/v1, Kind=IngressController"

$ oc explain alertmanager
error: Couldn't find resource for "monitoring.coreos.com/v1, Kind=Alertmanager"
$ oc explain alertmanager --api-version=monitoring.coreos.com/v1
error: Couldn't find resource for "monitoring.coreos.com/v1, Kind=Alertmanager"

$ oc explain InstallPlan
error: Couldn't find resource for "operators.coreos.com/v1alpha1, Kind=InstallPlan"
$ oc explain InstallPlan --api-version=operators.coreos.com/v1alpha1
error: Couldn't find resource for "operators.coreos.com/v1alpha1, Kind=InstallPlan"

$ oc explain HostSubnet --api-version=network.openshift.io/v1
error: Couldn't find resource for "network.openshift.io/v1, Kind=HostSubnet"

Comment 6 Michal Fojtik 2019-04-12 08:01:58 UTC

*** This bug has been marked as a duplicate of bug 1695176 ***

Comment 7 Maciej Szulik 2019-04-12 10:06:18 UTC
There are more stuff to fix than just that openapi CRD mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1695176, reopening.

Comment 8 Maciej Szulik 2019-04-12 10:08:04 UTC
*** Bug 1698644 has been marked as a duplicate of this bug. ***

Comment 9 Maciej Szulik 2019-04-19 12:06:30 UTC
Verified on 4.1.0-0.okd-2019-04-19-102439 the following are ok:

- oc explain console
- oc explain IngressController
- oc explain alertmanager
- oc explain InstallPlan
- oc explain HostSubnet

Comment 10 Maciej Szulik 2019-04-19 14:12:42 UTC
ClusterOperator and ClusterVersion should be fixed in https://github.com/openshift/cluster-version-operator/pull/168

Comment 11 zhou ying 2019-05-05 08:54:17 UTC
Confirmed with latest oc client , the issue has fixed: 
[root@192 ~]# oc version
Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.0", GitCommit:"05c6cd644", GitTreeState:"clean", BuildDate:"2019-05-04T16:58:50Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.4+d4a26b6", GitCommit:"d4a26b6", GitTreeState:"clean", BuildDate:"2019-05-04T18:12:07Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}


[root@192 ~]# oc explain clusteroperators --api-version="config.openshift.io/v1"
KIND:     ClusterOperator
VERSION:  config.openshift.io/v1

DESCRIPTION:
     <empty>

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/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/api-conventions.md#types-kinds

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

   spec	<map[string]> -required-
     spec hold the intent of how this operator should behave.

   status	<Object>
     status holds the information about the state of an operator. It is
     consistent with status information across the kube ecosystem.

[root@192 ~]# oc explain clusterversions --api-version="config.openshift.io/v1"
KIND:     ClusterVersion
VERSION:  config.openshift.io/v1

DESCRIPTION:
     <empty>

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/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/api-conventions.md#types-kinds

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

   spec	<Object> -required-
     spec is the desired state of the cluster version - the operator will work
     to ensure that the desired version is applied to the cluster.

   status	<Object>
     status contains information about the available updates and any in-progress
     updates.

Comment 13 errata-xmlrpc 2019-06-04 10:45:49 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-2019:0758


Note You need to log in before you can comment on or make changes to this bug.