Add clusteroperators and clusterversions to explain tests

[soltysh]

This is a followup from #22696 now that openshift/cluster-version-operator#168 merged
/assign @mfojtik

[mfojtik]

/retest

[mfojtik]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mfojtik, soltysh

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• test/extended/OWNERS [mfojtik,soltysh]

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

[runcom]

I'm not sure how we can move this type to openshift/api. machineconfigs depends on Ignition which we don't control so we can't add tags for autogenerated stuff. We're moving what we can from above in openshift/api#301 but there's something which we need to understand and fix yet

[soltysh]

@runcom not everything needs to be in openshift/api to get it tested. The gist is to publish those information when creating those CRDs.

[ingvagabund]

Is

$ oc explain clusteroperators
KIND:     ClusterOperator
VERSION:  config.openshift.io/v1

DESCRIPTION:

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	<map[string]> -required-
     spec hold the intent of how this operator should behave.

   status	<Object>
     status holds the information about the state of an operator. It is
     consistent with status information across the kube ecosystem.

the expected output? No need to describe fields of spec/status fields?

[soltysh]

@ingvagabund - yes, thanks!