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:
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
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
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.
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.
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
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". 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. version <string> version is the value of the operator's payload based version indicator when it was last successfully processed
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