Support YAML formatted OpenAPI schema

[yhrn]

Is your feature request related to a problem? Please describe.

Yes, at the moment kpt fn will choke on JSON files with long string, but I also think it would make sense to support this since all other file types referenced by your kustomization can be YAML encoded.

Describe the solution you'd like

Just being able to reference a YAML encoded schema from my Kustomization.

Additional context

kptdev/kpt/issues/2144 and #3934

[natasha41575]

@KnVerey @monopole is there any reason not to support this?

[aodinokov]

interesting topic

Just being able to reference a YAML encoded schema from my Kustomization.

What will be a format? something standard?
As an alternative for standard scheme representation - maybe we can allow providing k8s CRDs in their format? will there be a value in that? (that's of course - in addition to json format we have now.. not instead of json.. it's one of the standard representations)

Background:
in many cases we know k8s version where yamls docs will be used - its always possible to get that openapi scheme and reference kustomize to that. But with CRD things getting more complicated - it's necessary to apply them to k8s and pull openapi scheme in json format that will include all needed CRDs. if kustomize could support adding CRDs schemas - we wouldn't need k8s instance in that scenario.

BTW.. seems as something related: #3944
We should consolidate this onto the openapi field

[KnVerey]

If we add yaml support to that field, do we also need to support emitting it in kustomize openapi fetch? I'm a little skeptical of the value of yaml vs json here, given that these schema files are not exactly easy reading for humans either way. But assuming the implementation of support in both the field and the fetch command would be very small, I don't object to it being contributed.

The CRDs idea is interesting. Presumably whatever cluster(s) the configuration is intended for already have the CRDs in question deployed, but I could imagine a case where end users might not have enough access to run kustomize openapi fetch against them but would have access to the CRDs (i.e. in version control). WRT #3944, instead of getting rid of the crds field, we could swap out the implementation to be driven by the same transformer as openapi, i.e. two different input formats but a consistent underlying feature set / result. WDYT @natasha41575 ?

[natasha41575]

@KnVerey I'll add a comment to #3944, discussion should probably happen there.

WRT this issue, if there are no objections to supporting the OpenAPI schema in yaml I can add it to my todo list (or if anyone else wants to pick it up, feel free).