-
Notifications
You must be signed in to change notification settings - Fork 157
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
Add an automatically generated API client #144
Conversation
Thank you for the PR @aecay! IMHO, this feature is valid, I'm even surprised it hasn't come up before. Just as a heads-up, I won't be able to properly review this PR for a couple of weeks. At first glance, it looks OK but it does change a lot of things around and generation seems intricate. It might also clash with #138 changes. One request from my side now: please remove dependency updates (other than what is added by the client generation). Our policy is to do dependency updates in separate PRs and therefore, builds. As for your questions:
|
afd44b3
to
117f775
Compare
Hi @yorugac . Thanks for your feedback (and sorry it has taken me a while to get back to this -- I needed to chase approvals for the CLA internally at my employer -- which I'm happy to say is now sorted out). First of all, I've redone the branch with no dependency updates needed. 🎉 It turned out to be pretty simple (now that I know what I'm doing, more than I did when I started...)
As far as the issue about vendoring of dependencies goes, as far as I can see the flags for
What we need that import path to be is actually |
Hi @yorugac . Just checking on this PR -- is there anything outstanding that I need to do from your POV? Thanks 🙂 |
Hi @aecay, I've finally had some time to dig into your PR; my apologies for the delay. Code wise: the current branch seems fine to me but I intend to run some more tests with it -- will let you know if anything comes up. Ideally, I'd ask to include an example of how clientset is used if it's not too much trouble. Our README is becoming kind of overwhelmed though, so maybe a separate folder However, I've been trying to understand myself what's going on with different Kubernetes generators 😂 Partially due to issues you raised about the quirks of the tooling but also because in this PR, we get a new dependency: previously we used basically Could you please share your opinion on this? I don't think we got this request about clientset from anyone before and I'd like to have a more clear view on 'why' we add this prior to merging 🙂 E.g. you mentioned hitting some limits at which you started needing a dedicated clientset: are there some specific requirements that couldn't be resolved with the default client or is it too much boilerplate, etc.? |
@yorugac Thanks for this info. I was previously not familiar with this way of writing clients -- I had previously only used the approach with specific clientset per API. I am going to make an attempt at implementing our code with the kubebuilder method instead -- I think that will give us what we need! If it turns out that there are any issues encountered with kubebuilder, I may reopen this. But based on what I have seen so far, it should work out for us 🙂 Thanks again 🙂 |
Thanks for the update and clarifying the situation, @aecay! I hope the operator works for your use case. And certainly feel free to re-open if needs be 🙂 |
This PR is a first cut at adding a clientset for K6 objects that can be used programmatically in go (in the same way that vanilla k8s apis in v1/core, v1/batch, etc).
The PR is divided into 3 commits:
api
directory toapis
. This is driven by an (AFAICS undocumented) assumption in the kube-codegen codebase that all APIs will be located in a single package, and will be named according toPARENT-PKG/GROUP/VERSION
. Soapi/v1alpha
doesn't work quite right in the codegen (this piece of code which does something surprising when a package name is exactlyapi
doesn't help either....)There are a few outstanding questions I have:
go run
exists and this repo doesn't vendor its deps, the upstream advice seemed to me like not the best way to integrate the upstream library...PS If you are wondering, "what's this for," at $WORK we have an internal tool that does supervision of NFT tests in a k8s cluster. So far we use vanilla k8s Jobs for this (that run k6 on the inside) but we want to migrate to the operator. We need programmatic access to the
K6
resources in the cluster in in our test supervisor (written in go) so we can do things like "wait until the test has passed and then [push a docker image/deploy the version to a test env/etc]" I/we were able to get a certain distance with the generic REST interface, but at a certain point having properly typed API clients becomes very helpful....