Hmm, maybe I can wait for a client build from you. I can check what features or transport layer are missing from the generated client.
@searchymcsearchface Most of the client code is generated from a set of spec files from the upstream build.
- The OpenSeach plugins could probably have an native API in the client
- I’m not super familiar with this aspect of the python client, but having extensibility for additional plugins would be really helpful.
As long as the spec is generated somewhere, a generator can generate client code from those spec. I am not sure how the spec is generated or written. This seems belong to OpenSearch repo.
- Keep an eye on the project roadmap. The project uses semantic versioning, so no breaking changes are expected in 1.x but at 2.0 you’ll start to see some breaking changes (as an example,
main or whatever the new term ends up being).
I think @aparo and I both try not to break compatibility to talk to OpenSearch cluster. But we want to ask users to change their code using the new client library. As of how much change users have to make, that can be discussed. All in all, elasticsearch-py 7.x should be able to talk with OpenSearch since day 1. It sounds like a good enough compromise.