The Custom Resource Definition (CRD) for APIManager is missing descriptive comments for most fields within its .spec. As a result, the standard oc explain apimanager.spec command, which is a crucial tool for cluster administrators and developers, returns <no description> for these fields.

This deviates from established Kubernetes best practices, where all API fields should be documented in the source code to provide inline, discoverable documentation. This forces users to rely exclusively on external documentation, hindering usability and increasing the chances of misconfiguration.

Steps to Reproduce:

1. Have a cluster with the 3scale operator v2.15 installed.

1. Run the following command in the terminal:
   oc explain apimanager.spec

Actual Results:

The command output shows that most fields lack a description, making it difficult to understand their purpose without leaving the CLI.

GROUP:      apps.3scale.net
KIND:       APIManager
VERSION:    v1alpha1

FIELD: spec <Object>

DESCRIPTION:
     APIManagerSpec defines the desired state of APIManager

FIELDS:
  apicast  <Object>
     <no description>

  appLabel <string>
     <no description>

  backend  <Object>
     <no description>

  externalComponents <Object>
     <no description>

  highAvailability <Object>
     <no description>

  imagePullSecrets <[]Object>
     <no description>

  monitoring <Object>
     <no description>

  podDisruptionBudget <Object>
     <no description>

  resourceRequirementsEnabled <boolean>
     <no description>

  system <Object>
     <no description>

  tenantName <string>
     <no description>

  wildcardDomain <string> -required-
     Wildcard domain as configured in the API Manager object

  zync <Object>
     <no description> 

Expected Results:

The output of oc explain apimanager.spec should provide a helpful, descriptive text for every field, explaining its purpose and usage.

Business Impact:

This lack of inline documentation degrades the developer and administrator experience. It makes the APIManager resource less intuitive to configure, slows down development and troubleshooting, and goes against the self-documenting principles of Kubernetes-native APIs. Correcting this would significantly improve the operator's usability and align it with ecosystem standards.