test: [sig-cli] oc explain should contain proper spec+status for CRDs is failing frequently in CI, see search results: https://search.ci.openshift.org/?maxAge=168h&context=1&type=bug%2Bjunit&name=&maxMatches=5&maxBytes=20971520&groupBy=job&search=%5C%5Bsig-cli%5C%5D+oc+explain+should+contain+proper+spec%5C%2Bstatus+for+CRDs see: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-ocp-installer-e2e-azure-ovn-4.7/1333462646090895360 Error looks like: fail [github.com/openshift/origin/test/extended/cli/explain.go:442]: Unexpected error: <*errors.errorString | 0xc001d6e4c0>: { s: "oc explain [\"provisionings\" \"--api-version=metal3.io/v1alpha1\"] result {KIND: Provisioning\nVERSION: metal3.io/v1alpha1\n\nDESCRIPTION:\n <empty>} doesn't match pattern {(?s)DESCRIPTION:.*FIELDS:.*spec.*<.*>.*(status.*<.*>.*)?}", } oc explain ["provisionings" "--api-version=metal3.io/v1alpha1"] result {KIND: Provisioning VERSION: metal3.io/v1alpha1 DESCRIPTION: <empty>} doesn't match pattern {(?s)DESCRIPTION:.*FIELDS:.*spec.*<.*>.*(status.*<.*>.*)?} occurred This seems to be permafailing several jobs, and is currently blocking the nightly payloads from being accepted (the e2e-aws job is failing consistently with this issue).
This PR: https://github.com/openshift/cluster-baremetal-operator/pull/69 is a potential culprit. Runs after it merged have been failing consistently.
(In reply to Fabian von Feilitzsch from comment #1) > This PR: https://github.com/openshift/cluster-baremetal-operator/pull/69 is > a potential culprit. Runs after it merged have been failing consistently. This has started failing after oc explain tests have been by https://github.com/openshift/origin/pull/25708. The timing just happens to coincide with the merge of https://github.com/openshift/cluster-baremetal-operator/pull/69. ----------------------------------------------------------------------------------------------------------- In my deployed cluster, this is what we see: [stack@osp-shiftstack-05 dev-scripts]$ oc explain provisioning --api-version=metal3.io/v1alpha1 KIND: Provisioning VERSION: metal3.io/v1alpha1 DESCRIPTION: Provisioning contains configuration used by the Provisioning service (Ironic) to provision baremetal hosts. Provisioning is created by the OpenShift installer using admin or user provided information about the provisioning network and the NIC on the server that can be used to PXE boot it. This CR is a singleton, created by the installer and currently only consumed by the cluster-baremetal-operator to bring up and update containers in a metal3 cluster. 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> ProvisioningSpec defines the desired state of Provisioning status <Object> ProvisioningStatus defines the observed state of Provisioning
Sandhya is working on a fix. We are not sure why it's manifesting now, but in the migration from machine-api-operator to cluster-baremetal-operator, we had two copies of the baremetal CRD temporarily - one of which is older version and won't display the description. We already had work in progress to remove the one from MAO, which I've linked to the BZ. CVO has a very interesting behavior where it's constantly applying the MAO CRD, and then shortly after applying the one from CBO. There's a very short window where you'll get the older one which can't display the description when using `oc explain`.
*** This bug has been marked as a duplicate of bug 1880787 ***