Description of problem: Should add the description and FIELDS info for CRD catalogsourceconfig. # oc explain catalogsourceconfig KIND: CatalogSourceConfig VERSION: operators.coreos.com/v2 DESCRIPTION: <empty> Version-Release number of selected component (if applicable): 4.3.0-0.nightly-2019-11-10-185106 How reproducible: always Steps to Reproduce: 1. Install the OCP 4.3. 2. Login this cluster as a cluster-admin. 3. Check the CRD catalogsourceconfig $ oc explain catalogsourceconfig Actual results: # oc explain catalogsourceconfig KIND: CatalogSourceConfig VERSION: operators.coreos.com/v2 DESCRIPTION: <empty> Expected results: Should get the appropriate description for CRD catalogsourceconfig. $ oc explain catalogsourceconfig KIND: CatalogSourceConfig VERSION: operators.coreos.com/v2 DESCRIPTION: CatalogSourceConfig is used to enable an operator present in the OperatorSource to your cluster. Behind the scenes, it will configure an OLM CatalogSource so that the operator can then be managed by OLM. 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> Spec for a CatalogSourceConfig status <map[string]>
Nick, there are 3 crds that belong to marketplace: "operatorhub", "operatorsource","catalogsourceconfig". These 3 crds' explain are ok in OCP4.2 but the catalogsourceconfig and operatorsource miss the description and fields in OCP4.3 . I think the miss reason is important and I will modify the P&S since this bug only need fix the description info.
*** Bug 1771276 has been marked as a duplicate of this bug. ***
Problem: This issue was created due to the introduction of a new version of CustomResourceDefinitions (V1), which requires Structural Schemas [1]. With this change, any CRD that does not prune unknown fields will not return any output from `oc explain`. Solution: The CatalogSourceConfig and OperatorSource CRDs that Marketplace owns must be rebuilt using the Operator-SDK and must have `spec.preserveUnknownFields` set to `false`. Links: [1] https://kubernetes.io/blog/2019/06/20/crd-structural-schema/
Due to the nature of the solution, I am marking https://bugzilla.redhat.com/show_bug.cgi?id=1771276 as a duplicate and will address the `oc explain catalogsourceconfig` and `oc explain operatorsource` bugs in this Bugzilla.
Moving this bug to 4.4, will clone it to 4.3.
cv:4.4.0-0.nightly-2019-12-15-184910 result: $ oc explain opsrc KIND: OperatorSource VERSION: operators.coreos.com/v1 DESCRIPTION: OperatorSource is used to define the external datastore we are using to store operator bundles. 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> OperatorSourceSpec defines the desired state of OperatorSource status <Object> OperatorSourceStatus defines the observed state of OperatorSource 2)$ oc explain csc KIND: CatalogSourceConfig VERSION: operators.coreos.com/v2 DESCRIPTION: CatalogSourceConfig is used to enable an operator present in the OperatorSource to your cluster. Behind the scenes, it will configure an OLM CatalogSource so that the operator can then be managed by OLM. 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> CatalogSourceConfigSpec defines the desired state of CatalogSourceConfig status <Object> CatalogSourceConfigStatus defines the observed state of CatalogSourceConfig
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:0581