Closed jalvz closed 1 month ago
Pinging @elastic/integrations (Team:Integrations)
Pinging @elastic/fleet (Team:Fleet)
++ to this idea. It might also help with providing a single interface to the original Kibana Fleet API and the newer Fleet Server Fleet API.
:kool_aid_man: did someone say OpenAPI?
I'm more familiar with the choices for golang servers than clients, but there is a golang client for OpenAPI Generator. The docs have examples for trying the generator locally with npm
, brew
, or docker
.
Even if we choose to write a client versus using a generated one, that code can still benefit from importing the published spec.
bundled.json has some small gaps but should work great. I'm happy to hear about new users & use cases. Please file any issues with the spec/types in https://github.com/elastic/kibana & label with Team:Fleet
Excellent, thanks @jfsiii !
Very late update (sorry for that):
I gave this a shot a couple of months ago (see backlink above), but unfortunately code generation doesn't work 100%... it's more like 95%, but even if it is easy enough to glue by hand the broken bits, it means that it will take a bit more effort to maintain than what I hoped.
Another option would be to extract the relevant code out of elastic-package. I think that either way, it would be good to unify how we approach the Fleet API given the sprawling number of projects using it, and that everyone needs to keep up with API changes, support any versions, etc.
++ on coming up with a single Kibana client. I would expect it at first to only contain the functions really needed but it could be shared across multiple projects. Starting to extract it from elastic-agent sounds like a good idea.
Starting to extract it from elastic-agent sounds like a good idea.
@ruflin Did you mean elastic-package? 📎
Yes 🤦 But to be fair, elastic-agent also has Kibana bits inside ...
cc @Anaethelion I know generating go clients has your focus now too.
Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as Stale
to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1
. Thank you for your contribution!
I have been experimenting with generating some Go client code based on the OpenAPI definition for a small subset of the Fleet APIs. I was trying out github.com/deepmap/oapi-codegen/cmd/oapi-codegen.
Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as Stale
to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1
. Thank you for your contribution!
We have a number of projects consuming the Kibana Fleet API from Go. Some that I know of: elastic-package, e2e-testing, apm-server, apm-integration-testing.
I'd expect more projects will need it, and the maintenance burden to increase as Fleet evolves. I'd like to suggest a Fleet Go Client that all projects can benefit from. The most complete implementation at the time of writing appears to be elastic-package. We could start from there, and eventually auto-generate the code out of the API spec.
Thoughts?