ES1 is close to end of life in terms of commercial support from Elastic,
but not quite there (https://www.elastic.co/support/eol). Unfortunately
the ES1 and ES2 clients won't interoperate with their opposite versions.
Given that, I take it you would support having ES1 and ES2 bolts packaged
separately? This would somewhat like how we have storm-kafka and
storm-kafka-client for different Kafka versions.
On Thu, Sep 15, 2016 at 9:12 AM Bobby Evans <ev...@yahoo-inc.com.invalid>
> I personally don't use ES as part of my storm work, so I don't necessarily
> feel qualified to answer this. In general though I really do like to see
> storm come with batteries included. If ES1 is not end of life, and there
> is a community of people who want to continue using it/supporting it, I
> would say lets continue to do so. If that is not true, or if ES offers a
> backwards compatible client that could sway things for me to say lets just
> go forward with ES2. - Bobby
> On Wednesday, September 14, 2016 2:47 PM, Aaron Niskodé-Dossett <
> doss...@gmail.com> wrote:
> Hi all,
> I started a a discussion about this a while ago, but didn't take it to a
> conclusion (my $realjob, etc., etc.).
> There are multiple PRs open to provide an Elastic Search 2.x bolt to the
> Storm project. There are two different approaches:
> 1. Add side-by-side support for 2.x. Example:
> https://github.com/apache/storm/pull/1337 (*FULL DISCLOSURE*: this is my
> own PR). [I also have some functionality enhancements in this PR, but
> that's not relevant to this discussion.]
> 2. Upgrade existing bolt. Example,
> The drawback to approach 1 is that it duplicates a lot of code. The
> drawback to approach 2 is that it drops support for ES 1.x.
> ES 2.X has been out for a while and if we are serious about supporting it,
> we need to have a way to write to ES 2.X.
> I believe approach number 1 is ideal (again, it's my own PR) and possibly
> deprecating the existing 1.X bolt.
> I'd love to hear thoughts from others!