Generated CRDs do not populate top-level OpenAPI schema descriptions

[rajeshd2091]

Describe the feature request
While investigating kubectl explain, I noticed that all generated Istio CRDs have an empty top-level description.
For example:

kubectl explain virtualservice

GROUP:      networking.istio.io
KIND:       VirtualService
VERSION:    v1

DESCRIPTION:
    <empty>
.
.

even though explain virtualservice.spec , correctly shows the generated description:

kubectl explain virtualservice.spec

GROUP:      networking.istio.io
KIND:       VirtualService
VERSION:    v1

FIELD: spec <Object>


DESCRIPTION:
    Configuration affecting label/content routing, sni routing, etc. See more
    details at:
    https://istio.io/docs/reference/config/networking/virtual-service.html

Looking at the generated OpenAPI:
kubectl get --raw /openapi/v3/apis/networking.istio.io/v1 \ | jq '.components.schemas["io.istio.networking.v1.VirtualService"].description'

returns null.

I traced this to the CRD generator https://github.com/istio/tools/blob/master/cmd/protoc-gen-crd/openapiGenerator.go#L340-L341 . A straightforward implementation is to propagate spec.Description to the root schema, which makes kubectl explain display a description. However, this results in the same description appearing for both the resource and its spec.

Before preparing a PR, I'd like to understand the intended design:

• Should the root CRD schema reuse the protobuf message description?
• Or should the generator support a separate resource-level description (for example via a new +cue-gen annotation)?

Affected product area (please put an X in all that apply)

[ ] Configuration Infrastructure
[X] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[X] User Experience

Additional context:
This enhancement would improve the usability of generated Istio CRDs by populating top-level OpenAPI schema descriptions. Currently, kubectl explain <resource> shows an empty DESCRIPTION for generated CRDs, even though field and spec descriptions are available. Adding meaningful root descriptions would make Istio APIs easier to discover and understand directly from the CLI, without changing runtime behavior.