Support elasticsearch#14
Conversation
|
Thank you for the contribution! This is very unexpected. After all, this library was an attempt to build a simple, clean, and well designed facility to send logs directly to OpenSearch. Integrating support for ElasticSearch back into it is a seductive idea, but I'd like to understand why. Didn't you want to consider a contribution to the original project for Elasticsearch this library was forked from? |
I understand that, so feel (obviously) free of rejecting the PR. We can progress with our own fork, and didn't consider to contribute to a project without activity in the last five years. |
|
I'm very inclined towards merging the pr. I like the idea and the use case you just explained makes the reason obvious: OpenSearch - local dev and current stuff, Elastic cloud - long term compliance type of stuff. Thank you for your effort. I know how time consuming this is and it makes me happy to see that you still went through all the steps to contribute this improvement. Please let me sleep on it for a bit. I want to consider the design changes, test it against elastic, and maybe update the docs. I will get back to it next week. Btw, this library might have not receive a lot of commits over the last three years but only because there was so little to improve or add. It worked flawlessly with newer and newer versions of OpenSearch, without having any problems. I've rolled out a big maintenance update recently, mostly related to better test coverage, new PyPI release workflow, and cleaner automation around GitHub actions. I love this project. Despite its simplicity, it's the most successful thing I've created so far and I cherish it a lot. |
Add support to send logs into elasticsearch cloud. The actually required changes are those in first commit (minor bugs there), and second commit is mostly a kind of refactor to succeed on type checking.
Also added integration tests with latest elasticsearch container image (same than opensearch ones, changing just handler instantiation)