Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow kustomize users to specify their own OpenAPI schema #2206

Closed
4 tasks done
natasha41575 opened this issue Dec 21, 2020 · 7 comments
Closed
4 tasks done

Allow kustomize users to specify their own OpenAPI schema #2206

natasha41575 opened this issue Dec 21, 2020 · 7 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/cli Categorizes an issue or PR as relevant to SIG CLI. stage/beta Denotes an issue tracking an enhancement targeted for Beta status

Comments

@natasha41575
Copy link
Contributor

natasha41575 commented Dec 21, 2020

Enhancement Description

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

@k8s-ci-robot k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Dec 21, 2020
@k8s-ci-robot
Copy link
Contributor

k8s-ci-robot commented Dec 21, 2020

@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
Copy link
Contributor Author

natasha41575 commented Dec 21, 2020

/sig cli

@afirth
Copy link
Member

afirth commented May 7, 2021

@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
Copy link
Contributor Author

natasha41575 commented May 7, 2021

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
Copy link
Contributor

KnVerey commented May 19, 2021

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

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label May 19, 2021
@natasha41575
Copy link
Contributor Author

natasha41575 commented May 20, 2021

/stage beta

@k8s-ci-robot k8s-ci-robot added the stage/beta Denotes an issue tracking an enhancement targeted for Beta status label May 20, 2021
@natasha41575
Copy link
Contributor Author

natasha41575 commented May 20, 2021

@KnVerey updated the description with your suggestions

I'm also closing this issue because we have finished implementing what we intended to with this KEP. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/cli Categorizes an issue or PR as relevant to SIG CLI. stage/beta Denotes an issue tracking an enhancement targeted for Beta status
Projects
None yet
Development

No branches or pull requests

4 participants