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

/sig cli

@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!

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.

/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)