[PROPOSAL] Redesign the SDKClient

[dbwiddis]

What/Why

What are you proposing?

We should redesign the SDKClient from scratch, without referring to the existing client which is trying to do too many things and doing some of them poorly.

Our original vision (if we ever had one) for the SDKClient has morphed over time into an increasingly unmaintainable pile of spaghetti code. It looks like we started wanting to use it just as a wrapper for the OpenSearch Client for Java (opensearch-java), but then:

• We pivoted to use RestHighLevelClient for migration and added that
• We tried to handle all the existing plugin calls but are using a different Client Interface than the plugins
• We added support for transport actions to parallel what NodeClient does
• We added support for remote/proxy transport actions on other extensions
• We added support for RequestOptions (headers)

Core capabilities we need:

• Handle transport actions (client.execute())
• Provide a bridge for migration, internally using RestHighLevelClient calls and attempting to use the exact signature as existing clients including the same request/response classes

What users have asked for this feature?

#612, #729, #430, #616, TBD issue on serverless

What problems are you trying to solve?

Replace existing usages of NodeClient implementations in plugins, specifically

• Transport Actions (client.execute()) internal to the extension
• Index, Cluster, and Admin client actions that need to be handled by a REST client
• Support for headers/authentication associated with the REST client

What is the developer experience going to be?

For migrating existing plugins, a minimal diff.

For developing new plugins, a set of clearly documented tools providing needed capabilities.

Why should it be built? Any reason not to?

Properly handle initialization
Properly handle resource usage/leakage
Properly handle multithreading
Permit DRY

What will it take to execute?

Re-thinking/re-scoping what the object does and does not do.

Any remaining open questions?

• Should we be making the Java Clients part of the SDK API at all or just documenting how to use them? [BUG] SDKClient implementations are not thread safe and are difficult to close #612
• Should we be initializing the (deprecated) RestClient as a singleton and how does that fit into the initialization sequence? [BUG] OpenSearch and Extension host and port are required before initializing either #729
• How do we avoid resource leaks if we do initialize it ourself? We have a close method but that's pretty useless on our singleton. Can we follow a try-with-resources model for all usages of the client?
• Should we try to use the same client Request/Response classes that plugins do with the NodeClient, which differ slightly in some cases with the RestHighLevelClient? (Would require a lot of translating one request class to another)

[dblock]

I am a big fan of deferring client responsibilities to opensearch-java and taking a runtime dependency on it.

[dbwiddis]

I am a big fan of deferring client responsibilities to opensearch-java and taking a runtime dependency on it.

Can you be a little more specific what this means, @dblock ? Currently we don't do much with the opensearch-java client other than initialize it from our settings. We weren't planning on doing more; in fact, I'm proposing not depending on them or providing them at all and just giving a few lines of code a user can write themselves.

[dblock]

I think we're saying the same thing @dbwiddis. If an extension needs to make "standard" RESTful API calls to an OpenSearch instance it should know how, but not use the code in the SDK to do it.