Allow kustomize users to specify their own OpenAPI schema

[natasha41575]

Enhancement Description

• One-line enhancement description (can be used as a release note): Add an openapi field to the kustomization file to allow users to specify their own OpenAPI schemas to use
• Kubernetes Enhancement Proposal:
• Discussion Link: Strategic merge support for CRDs kubernetes-sigs/kustomize#2825
• Primary contact (assignee): @natasha41575
• Responsible SIGs: cli
• Enhancement target (which target equals to which milestone):
  • Beta release target (x.y): 1.22
• Beta
  • KEP (k/enhancements) update PR(s):
    • https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2206-openapi-features-in-kustomize
    • change openapi features in kustomize KEP status to implementable #2375
  • Code (k/k) update PR(s):
    • added kustomize openapi fetch command to get schema from local cluster kubernetes-sigs/kustomize#3621
    • add openapi/path field to use custom openapi schema document kubernetes-sigs/kustomize#3617
  • Docs (k/website) update PR(s): update kustomize docs for patches and openapi kubernetes-sigs/cli-experimental#131

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[k8s-ci-robot]

@natasha41575: The label(s) sig/sig-cli cannot be applied, because the repository doesn't have them

In response to this:

/sig sig-cli

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.

[natasha41575]

/sig cli

[afirth]

@natasha41575 thanks heaps for implementing this!

2 Qs:
1.
when running kustomize openapi fetch <CRD> it seems the info is printed to stdout, which results in an invalid schema. Is there an option I'm missing here?

$ kustomize openapi fetch elasticsearches.elasticsearch.k8s.elastic.co 2>/dev/null | head -n3

Fetching schema from cluster
{
  "definitions": {

Additionally when piping the output this seems to leave kubectl broken (proxy stays running forever)

$ kustomize openapi fetch elasticsearches.elasticsearch.k8s.elastic.co | head -n3
# works
$ kustomize openapi fetch elasticsearches.elasticsearch.k8s.elastic.co --stack-trace
Fetching schema from cluster
<nil> F0507 11:56:37.055937 2173710 proxy.go:160] listen tcp 127.0.0.1:8081: bind: address already in use

Error fetching schema from cluster.
Please make sure port 8081 is available, kubectl is installed, and its context is set correctly.
Installation and setup instructions: https://kubernetes.io/docs/tasks/tools/install-kubectl/

$ ps aux | grep $(lsof -ti:8081)
afirth   2168653  0.5  0.2 145668 34468 pts/2    Sl   11:49   0:00 /home/afirth/.asdf/installs/kubectl/1.16.15/bin/kubectl proxy --port=8081 &

Let me know if you want me to open tix for these somewhere else. Thanks again for building this!

[natasha41575]

Thanks for your questions! There are a couple things here.

1. kustomize openapi fetch does not have an argument. It will hit the /openapi/v2 endpoint of the apiserver and return the whole document; there is no <CRD> argument. I'd be very surprised and confused to learn that adding a <CRD> changes the output at all.

2. I also realized that "Fetching schema from cluster" was printed out, which messes things up for people who are piping stdout. I've removed it, see update openapi fetch command kubernetes-sigs/kustomize#3854. This will be reflected in the next release of kustomize.

3. With the same PR mentioned above, the proxy/port shouldn't be an issue because the mechanism for hitting the /openapi/v2 will be different.

Thank you for using this feature and testing it out for us. Hopefully your issues will be resolved in the next release.

[KnVerey]

/kind feature
/assign @natasha41575

@natasha41575 I'm thinking this should have "/stage beta" since it has already been implemented in Kustomization (which itself is a beta kind) and is not behind an alpha flag. I'm also thinking the milestone should be set to 1.22, since that's both when the feature merged in Kustomize and likely the kubectl release it will show up in. Could you please update the enhancement description? (with whatever you think is best if you don't agree with my assessment)