WIP Add kubectl explain

[routerhan]

This PR enables the kubectl explain of build and buildrun resources, by adding the preserveUnknownFields property in CRD spec respectively.

The standard output would be as following : (e.g. buildrun)

KIND:     BuildRun
VERSION:  build.dev/v1alpha1
DESCRIPTION:
     BuildRun is the Schema for the buildruns API
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>
     BuildRunSpec defines the desired state of BuildRun
   status       <Object>
     BuildRunStatus defines the observed state of BuildRun

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign otaviof
You can assign the PR to them by writing /assign @otaviof in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

Hi @routerhan. Thanks for your PR.

I'm waiting for a redhat-developer member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[qu1queee]

This PR is coming from Ching(IBM intern) that is working with us, fyi @sbose78

[sbose78]

/ok-to-test

[sbose78]

and @otaviof could you add folks to the whitelist please?

[sbose78]

Thank you Ching!

Could you please confirm that this would not be overwritten by operator-sdk generate .. commands?

[zhangtbj]

Hi @routerhan ,

If you run the operator-sdk generate crds, the new change will be overwritten.

Let us search and ask first if we can add a property in api spec to auto generate this property in CRD.

I didn't find a good solution, but there are some discussions, like this:
improbable-eng/etcd-cluster-operator#116

I think you can also help investigate or ask in community how to do that.

[routerhan]

@sbose78 @zhangtbj
Thank you for the information. I will investigate that.

[routerhan]

I opened a new issue to ask about if operator-sdk framework support this features.
Please refer to operator-framework/operator-sdk#2886

[qu1queee]

@routerhan seems you got a nice response in operator-framework/operator-sdk#2886 (comment) , pls take a look

[routerhan]

According to the response, we are not able to set preserveUnknownFields to be false when generating a v1beta1 CRD.

See more about the kubebuilder documentation : https://book.kubebuilder.io/reference/markers/crd-processing.html