Upgrade elasticsearch ruby client.
- Dominant language
- Java
- Stars
- 14.9k
- Forks
- 3.5k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 88
Description
With the best practice, `elasticsearch` ruby client with its forward compatibility, the LS core is using one major version behind the stack - https://github.com/elastic/logstash/blob/f2400df86b3a367091d5aecefcef933ba20d0695/logstash-core/logstash-core.gemspec#L82
In 10.x, the client needs to be upgraded to 9.last in:
- core: https://github.com/elastic/logstash/blob/f2400df86b3a367091d5aecefcef933ba20d0695/logstash-core/logstash-core.gemspec#L82
- es-input: https://github.com/logstash-plugins/logstash-input-elasticsearch/blob/68158289c068d130bac2a22828494544e1496191/logstash-input-elasticsearch.gemspec#L29
- es-filter: https://github.com/logstash-plugins/logstash-filter-elasticsearch/blob/a7af6a775dd1586e7925d7f17755ece7be6a4df6/logstash-filter-elasticsearch.gemspec#L24
Also, note that in 9.4.1 elasticsearch-api and elasticsearch-transport clients had an issue that duplicate header may appear. We need to have a mechanism to avoid consuming this version since we set the header in the plugins.
cc: @donoghuc
Contributor guide
Research direction
Start with the dependency declarations at logstash-core/logstash-core.gemspec, logstash-input-elasticsearch/logstash-input-elasticsearch.gemspec, and logstash-filter-elasticsearch/logstash-filter-elasticsearch.gemspec. Check the Elasticsearch client compatibility guidance and the 9.4.1 duplicate-header issue before changing the versions. Done means the three dependencies use the intended 9.x client without consuming 9.4.1, while preserving the plugins' header behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- elasticsearch, ruby
- Domain
- backend, databases
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100