Bug 1880787
| Summary: | No description for Provisioning CRD for `oc explain` | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Jason Boxman <jboxman> |
| Component: | Cloud Compute | Assignee: | Angus Salkeld <asalkeld> |
| Cloud Compute sub component: | BareMetal Provider | QA Contact: | Shelly Miron <smiron> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | urgent | ||
| Priority: | urgent | CC: | agarcial, asalkeld, beth.white, brad, fabian, fsimonce, rbartal, stbenjam, wking, yjoseph, zbitter |
| Version: | 4.6 | Keywords: | Triaged, UserExperience |
| Target Milestone: | --- | ||
| Target Release: | 4.7.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
Previously `oc explain Provisioning` did not produce the details that were in the CRD as we were using an old version of the CRD definition.
Fix:
The version of the CRD has been updated and now `oc explain Provisioning` works as expected.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-02-24 15:18:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This CRD is in the MAO repo, so changing the component: https://github.com/openshift/machine-api-operator/blob/master/install/0000_30_machine-api-operator_04_metal3provisioning.crd.yaml I assume this file is automatically generated from the controller in the cluster-baremetal-operator (which is not part of the 4.6 release). To fix it we either need to * regenerate it using API version apiextensions.k8s.io/v1 (instead of v1beta1 - use the --crd-version=v1 flag to operator-sdk, not sure about kubebuilder); or * manually edit in "x-kubernetes-preserve-unknown-fields: false" to make it into a structural schema (see https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema). This commit will fix the issue: https://github.com/openshift/cluster-baremetal-operator/commit/f38ec83878090ea18cf0a9482a710b35332df44d If testing remember to completely delete the CRD first and re-create it. When I tested, running an update did not cause 'oc explain' to show the new details (maybe it's cached somewhere?). (In reply to Angus Salkeld from comment #4) > When I tested, running an update did not cause 'oc explain' to > show the new details (maybe it's cached somewhere?). There's a note about that here: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#field-pruning "CRDs converted from apiextensions.k8s.io/v1beta1 to apiextensions.k8s.io/v1 might lack structural schemas, and spec.preserveUnknownFields might be true. For migrated CustomResourceDefinitions where spec.preserveUnknownFields is set, pruning is not enabled and you can store arbitrary data. For best compatibility, you should update your custom resources to meet an OpenAPI schema, and you should set spec.preserveUnknownFields to true for the CustomResourceDefinition itself." It sounds like because the default has flipped, simply updating the CRD with a v1 version generated by kubebuilder (which does not explicitly assert the new default) will leave the preserveUnknownFields at its previous setting. (I tend to think we shouldn't be too worried about this.) [kni@provisionhost-0-0 ~]$ oc version
Client Version: 4.7.0-0.nightly-2020-10-27-051128
Server Version: 4.7.0-0.nightly-2020-10-27-051128
Kubernetes Version: v1.19.0+e67f5dc
Before re-creating the CRD:
----------------------------------
[kni@provisionhost-0-0 ~]$ oc explain Provisioning
KIND: Provisioning
VERSION: metal3.io/v1alpha1
DESCRIPTION:
<empty>
After re-creating the CRD:
----------------------------------
[kni@provisionhost-0-0 ~]$ oc explain Provisioning
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
Is this considered as fixed although the CRD needed to be re-created each time?
I think it failed QA because MAO still has the older CRD which is in the process of being removed. 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`. *** Bug 1903275 has been marked as a duplicate of this bug. *** This is affecting OCP release payloads, as there's a test to check if each CRD has a description. When it catches it in that short window when the older CRD is present, the test is failing and blocking the release. (In reply to Stephen Benjamin from comment #10) > This is affecting OCP release payloads, as there's a test to check if each > CRD has a description. When it catches it in that short window when the > older CRD is present, the test is failing and blocking the release. I don't know that it's a short window; I think it's whichever is created first wins. So now that the MAO is no longer installing the CRD, this should Just Work(TM) on fresh deployments. But it quite possibly still won't work after an upgrade from 4.6. > I don't know that it's a short window; I think it's whichever is created first wins.
If you had both MAO and CBO with the CRD in their manifests, CVO alternates between applying the two over and over again. It's visible in the logs for CVO. If you sit with `watch oc explain`, you'll periodically catch the MAO one not showing a description. It's short, so maybe 1 out of ~50 times.
Verified on version (in disconnected env & connected env):
[kni@provisionhost-0-0 ~]$ oc version
Client Version: 4.7.0-0.nightly-2020-12-04-013308
Server Version: 4.7.0-0.nightly-2020-12-04-013308
Kubernetes Version: v1.19.2+ad738ba
[kni@provisionhost-0-0 ~]$ oc explain Provisioning
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
Doc Text: Previously `oc explain Provisioning` did not produce the details that were in the CRD. The version of the CRD has been updated and now `oc explain Provisioning` works as expected. Doc type: bug 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 (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), 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/RHSA-2020:5633 |
Description of problem: There is no description for the Provisioning CRD in `oc explain`. How reproducible: Always. Steps to Reproduce: `oc explain Provisioning` Actual results: KIND: Provisioning VERSION: metal3.io/v1alpha1 DESCRIPTION: <empty> Expected results: A description.