search

opensearch-project / opensearch-py-ml

Apache License 2.0
31 stars 61 forks source link

[PROPOSAL] Merge with opensearch-py? #372

Open dblock opened 6 months ago

dblock commented 6 months ago

Is your feature request related to a problem?

Users are confused with the many OpenSearch clients. Is opensearch-py-ml one too many?

The dsl client has a high-level and a low-level interface. For AWS users there’s also boto3 (see https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-sdk.html#serverless-sdk-python), used to create collections. We have opensearch-dsl-py client that has been deprecated since 2.1 and will be archived.

What solution would you like?

Merge opensearch-py-ml into opensearch-py.

What alternatives have you considered?

Leave things as is.

saimedhi commented 5 months ago

I've reviewed the repository code, and I feel merging opensearch-py-ml into opensearch-py is feasible. I estimate it would take approximately 3 weeks to 1 month to merge all the code and tests, ensuring everything runs smoothly.

dblock commented 1 month ago

Catch All Triage - 1 2 3 4 5

rbpasker commented 4 weeks ago

I think it might be worthwhile to conduct a high-level review of the ML API before merging it in. There are consistency and orthogonality issues that caused me a lot of confusion.

Here would be some things to discuss:

  1. HTTP or CRUD idiom -- should the methods be named put, get, post, delete (as in the OpenSearch main API); or create, update, delete (as in ML)?
  2. should the methods be suffixed with the object name? eg, (using the HTTP idiom) Connector.put_connector() or Connector.put()?
  3. There are some differences in kwarg names that should be the same across the APIs, eg body and payload for the HTTP contents

my personal preference is for CRUD without repeating the object name, eg Connector.create()