-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add support for OpenSearch backend #348
Conversation
Hi @maximepln, thanks a lot for this submission. I will take a look at it shortly. Regarding your choice of going with two different backends (with some duplicate code), I ended up doing the exact same thing to support MQL in Cloud Monitoring on top of the existing MQF backend. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor changes left. Thanks for the good work!
Thanks for the feedback @lvaylet, I updated to code to use Don't hesitate if you have any other comments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for going over every instance of OpenSearch in the commits. I suggested a couple more changes to remain consistent with other backends (Cloud Monitoring specifically).
Hi @lvaylet, Sorry for the delay to respond, I was away on holiday. Hope everything is fine now |
hello @lvaylet, any updates ? |
I will take a look tomorrow afternoon. |
* feat(Backend): Add Opensearch as a backend provider * fix: naming of package * fix: disable pylint code duplication * fix: rename opensearch to OpenSearch * fix: Opensearch to OpenSearch and opensearch to open_search * fix: few typo comments
Everything is in the title but I will add a bit of details
The goal of that PR is to implement a new backend provider
Opensearch
For instance, I opened an issue about this there: Issue 346,
in which I explained why the
Elasticsearch
wasn't usable withOpensearch
As you will see, some code could have been mutualised between the two backend. But as we don't know the direction that will take the 2 backends in the future, and due to the fact that they could become quite different, I chose to avoid adding too much complexity.
Furthermore, most of the people will work on either
Opensearch
orElasticsearch
so having a common codebase could become complicated when wanting to add new features.Everything is documented in the right directories and unit tests & mocks were implemented.