Bug 1769167

Summary:	Missing openapi CRD definitions for oc explain for configs.samples.operator.openshift.io
Product:	OpenShift Container Platform	Reporter:	Wenjing Zheng <wzheng>
Component:	Samples	Assignee:	Gabe Montero <gmontero>
Status:	CLOSED ERRATA	QA Contact:	XiuJuan Wang <xiuwang>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.3.0	CC:	adam.kaplan, aos-bugs, bparees, jokerman, 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:16 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Wenjing Zheng 2019-11-06 02:17:47 UTC

This bug was initially created as a copy of Bug #1708600

I am copying this bug because: 



+++ This bug was initially created as a clone of Bug #1708597 +++

Description of problem:
Copied from bug 1705746, should add the description info for these CRDs so that `oc explain` can work when try to explain configs.imageregistry.operator.openshift.io crd:
$ oc explain configs.imageregistry.operator.openshift.io |grep -i description -A 3
DESCRIPTION:
     <empty>
$ oc explain configs.samples.operator.openshift.io 
KIND:     Config
VERSION:  imageregistry.operator.openshift.io/v1

DESCRIPTION:
     <empty>


Version-Release number of selected component (if applicable):
4.3.0-0.nightly-2019-11-02-092336

How reproducible:
Always

Steps to Reproduce:
1.$ oc explain configs.imageregistry.operator.openshift.io
2.$ oc explain configs.samples.operator.openshift.io 
3.$ oc explain openshiftcontrollermanagers

Actual results:
Get nothing about the description.

Expected results:
Should get the appropriate description.

Additional info:

Comment 1 Gabe Montero 2019-11-08 18:44:55 UTC

A quick note @Wenjing, the command oc explain config --api-version=samples.operator.openshift.io/v1 will at least get you 

KIND:     Config
VERSION:  samples.operator.openshift.io/v1

DESCRIPTION:
     <empty>

But otherwise, yes, we still have work to do to react to the k8s 1.16.2 rebase and the resulting impacts on `oc explain` that Maciej 
emailed on aos-devel about last month.  Until then, we lost the functional `oc explain` that we had for samples/imageregistry operators 
that we had when 4.2 GA'ed.

There has been some inconsistency with `oc explain` and 4.x CRDs that has transpired wrt invoking commands like oc explain configs.samples.operator.openshift.io.
There have been times when it worked, and times when it didn't.

Ben Paress has opened https://bugzilla.redhat.com/show_bug.cgi?id=1725981 for being able to say oc explain configs.samples.operator.openshift.io instead of oc explain config --api-version=samples.operator.openshift.io/v1

When we get the fix ready for this, if https://bugzilla.redhat.com/show_bug.cgi?id=1725981 has not been resolved, you might have to use oc explain config --api-version=samples.operator.openshift.io/v1

Comment 2 Gabe Montero 2019-11-11 20:27:21 UTC

OK, https://github.com/openshift/api/pull/513 is up ... once that merges, it looks like we'll need bumps in
-openshift/client-go .... something akin to https://github.com/openshift/client-go/pull/109
-openshift/cluster-samples-operator  .... something akin to https://github.com/openshift/cluster-kube-controller-manager-operator/pull/302
for just the CRD generation.

Then changes in openshift/cluster-samples-operator to switch over to use the openshift/api types as well.

Also note, the bug description mentions running oc explain for image registry and OCM operators.  The changes for this bug will only address samples operator.

I see in shiftzilla there are bugs opened against image registry and OCM for oc explain there

Comment 3 Gabe Montero 2019-11-12 21:13:33 UTC

OK, some progress.

Using a cluster from https://github.com/openshift/cluster-samples-operator/pull/197
I get:

gmontero ~/go/src/github.com/openshift/cluster-samples-operator/pkg  (fix-oc-explain-k8s-116)$ oc explain config --api-version=samples.operator.openshift.io/v1
KIND:     Config
VERSION:  samples.operator.openshift.io/v1

DESCRIPTION:
     Config contains the configuration and detailed condition status for the
     Samples Operator.

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> -required-
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec	<Object> -required-
     ConfigSpec contains the desired configuration and state for the Samples
     Operator, controlling various behavior around the imagestreams and
     templates it creates/updates in the openshift namespace.

   status	<Object>
     ConfigStatus contains the actual configuration in effect, as well as
     various details that describe the state of the Samples Operator.

However, if I try to use --recursive=true to get the subfields for spec and status, I get blank information except for the very top:
gmontero ~/go/src/github.com/openshift/cluster-samples-operator/pkg  (fix-oc-explain-k8s-116)$ oc explain config --api-version=samples.operator.openshift.io/v1 --recursive=true
KIND:     Config
VERSION:  samples.operator.openshift.io/v1

DESCRIPTION:
     Config contains the configuration and detailed condition status for the
     Samples Operator.

FIELDS:
   apiVersion	<string>
   kind	<string>
   metadata	<Object>
      annotations	<map[string]string>
      clusterName	<string>
      creationTimestamp	<string>
      deletionGracePeriodSeconds	<integer>
      deletionTimestamp	<string>
      finalizers	<[]string>
      generateName	<string>
      generation	<integer>
      labels	<map[string]string>
      managedFields	<[]Object>
         apiVersion	<string>
         fieldsType	<string>
         fieldsV1	<map[string]>
         manager	<string>
         operation	<string>
         time	<string>
      name	<string>
      namespace	<string>
      ownerReferences	<[]Object>
         apiVersion	<string>
         blockOwnerDeletion	<boolean>
         controller	<boolean>
         kind	<string>
         name	<string>
         uid	<string>
      resourceVersion	<string>
      selfLink	<string>
      uid	<string>
   spec	<Object>
      architectures	<[]string>
      managementState	<string>
      samplesRegistry	<string>
      skippedImagestreams	<[]string>
      skippedTemplates	<[]string>
   status	<Object>
      architectures	<[]string>
      conditions	<[]Object>
         lastTransitionTime	<string>
         lastUpdateTime	<string>
         message	<string>
         reason	<string>
         status	<string>
         type	<string>
      managementState	<string>
      samplesRegistry	<string>
      skippedImagestreams	<[]string>
      skippedTemplates	<[]string>
      version	<string>

Don't know yet if that is a problem with `oc` or with how we generated the CRD.  Will start investigating.


Adam/Ben FYI.

Comment 4 Gabe Montero 2019-11-13 19:39:56 UTC

Figured it out ... you have to specify the fieldName now 

i.e. oc explain consoleexternalloglinks.spec

will bring up my changes and get the analogous item for configs.samples in a bit.

Comment 5 Gabe Montero 2019-11-13 20:42:17 UTC

yep the invocations are:

1) oc explain config.spec --api-version=samples.operator.openshift.io/v1
2) oc explain config.status --api-version=samples.operator.openshift.io/v1
3) oc explain config --api-version=samples.operator.openshift.io/v1

Comment 7 XiuJuan Wang 2019-11-22 06:33:41 UTC

Verified with version
$ oc version
Client Version: v4.3.0
Server Version: 4.3.0-0.nightly-2019-11-21-122827
Kubernetes Version: v1.16.2

$oc explain config --api-version=samples.operator.openshift.io/v1
KIND: Config
VERSION: samples.operator.openshift.io/v1

DESCRIPTION:
Config contains the configuration and detailed condition status for the
Samples Operator.

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> -required-
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec <Object> -required-
ConfigSpec contains the desired configuration and state for the Samples
Operator, controlling various behavior around the imagestreams and
templates it creates/updates in the openshift namespace.

status <Object>
ConfigStatus contains the actual configuration in effect, as well as
various details that describe the state of the Samples Operator.

$ oc explain config.spec --api-version=samples.operator.openshift.io/v1

KIND: Config
VERSION: samples.operator.openshift.io/v1

RESOURCE: spec <Object>

DESCRIPTION:
ConfigSpec contains the desired configuration and state for the Samples
Operator, controlling various behavior around the imagestreams and
templates it creates/updates in the openshift namespace.

FIELDS:
architectures <[]string>
architectures determine which hardware architecture(s) to install, where
x86_64, ppc64le, and s390x are the only supported choices currently.

managementState <string>
managementState is top level on/off type of switch for all operators. When
"Managed", this operator processes config and manipulates the samples
accordingly. When "Unmanaged", this operator ignores any updates to the
resources it watches. When "Removed", it reacts that same wasy as it does
if the Config object is deleted, meaning any ImageStreams or Templates it
manages (i.e. it honors the skipped lists) and the registry secret are
deleted, along with the ConfigMap in the operator's namespace that
represents the last config used to manipulate the samples,

samplesRegistry <string>
samplesRegistry allows for the specification of which registry is accessed
by the ImageStreams for their image content. Defaults on the content in
https://github.com/openshift/library that are pulled into this github
repository, but based on our pulling only ocp content it typically defaults
to registry.redhat.io.

skippedImagestreams <[]string>
skippedImagestreams specifies names of image streams that should NOT be
created/updated. Admins can use this to allow them to delete content they
don’t want. They will still have to manually delete the content but the
operator will not recreate(or update) anything listed here.

skippedTemplates <[]string>
skippedTemplates specifies names of templates that should NOT be
created/updated. Admins can use this to allow them to delete content they
don’t want. They will still have to manually delete the content but the
operator will not recreate(or update) anything listed here.

$ oc explain config.status --api-version=samples.operator.openshift.io/v1
KIND: Config
VERSION: samples.operator.openshift.io/v1

RESOURCE: status <Object>

DESCRIPTION:
ConfigStatus contains the actual configuration in effect, as well as
various details that describe the state of the Samples Operator.

FIELDS:
architectures <[]string>
architectures determine which hardware architecture(s) to install, where
x86_64 and ppc64le are the supported choices.

conditions <[]Object>
conditions represents the available maintenance status of the sample
imagestreams and templates.

managementState <string>
managementState reflects the current operational status of the on/off
switch for the operator. This operator compares the ManagementState as part
of determining that we are turning the operator back on (i.e. "Managed")
when it was previously "Unmanaged".

version <string>
version is the value of the operator's payload based version indicator when
it was last successfully processed

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