[PROPOSAL] Plugins Python Client Interface

What kind of business use case are you trying to solve? What are your requirements?

Although the current state of opensearch-py can connect to opensearch database and do transactions seamlessly, To use plugins features like Search Plugin or Monitoring Plugin, one needs to follow the REST guideline from docs and need to make the requests and the workflow manually. I, right now have a personal requirement of the alerting feature from the Monitoring Plugin to be implemented in a pythonic way.

What is the problem? What is preventing you from meeting the requirements? The problem is the lack of python support for the plugins as most of the organizations using the python client would probably use monitoring and other plugin features as well. Lack of this particular feature would mean, one needs to use opensearch-py in one hand and also using the REST API from the docs on the other hand, creating a mixed feeling in the developers heart, unhealthy code and probably some security flaws in the developer’s code as well.

What are you proposing? What do you suggest we do to solve the problem or improve the existing situation? I am proposing a pythonic implementation of the plugins API, which would look something like this:

from opensearchpy import OpenSearch
from opensearchpy.plugins.alerting import Monitors, MonitorType, Trigger

client = OpenSearch(...)

# To Get Monitor from it's ID
client.plugins.alerting.get_monitor('X9umLn0B5FPOmJ6VSaWe')

# To Create a new Monitor
query = {...}
client.plugins.alerting.create_monitor(query)

# To get all Destinations
client.plugins.alerting.get_destination()

...

What are your assumptions or prerequisites? N/A

What are remaining open questions? List questions that may need to be answered before proceeding with an implementation.

• Is this feature contextual to this particular project or is it more contextual to opensearch-dsl-py or should someone make a different project to interface the plugins?
• Assuming that this proposal is contextual to either this project or the dsl one, what kind of directory structure should I proceed with. Should I add a directory named contrib or plugins ?
• Should I go for as much pythonic way I can or should I ask most of the input arguments as Dictionary?
• Any coding convention that I should be following ?

[stockholmux]

@gabrielcocenza The API is the way to do it right now. OpenSearch follows SemVer so the concern of the APIs breaking will only be an issue at a major versions. I would think the charm you’re developing would need to change at that time anyway.

Also, the ES client’s CCR is similar in name only - I don’t believe that theres is compatibility between the OpenSearch and ES implementations of CCR.

All this being said, I agree though, yes, going forward it would be nice to have CCR abstracted into the library 😃

[axeoman]

Yea, I agree that this is a useful feature and thanks a lot for that 👍