Now might be a time to consider making version-sensitive modules ((kafk, ES)
maven multi-modules.
I've never really liked "storm-Kafka" and "storm-kafka-client" as
differentiators of Kafka 0.9..X and 0.10.x. I'd tend toward something like:
storm-Kafka/
/0.9.x
/0.10.x
I would think the same thing would apply to ES.
I'm +1 for supporting both versions, with careful consideration wrt how and
when to deprecate or EOL support for a version line.
-Taylor
> On Sep 20, 2016, at 7:30 PM, Aaron Niskodé-Dossett <[email protected]> wrote:
>
> Thanks everyone. Could one or more committers +1 the PR that would support
> both versions?
>
> https://github.com/apache/storm/pull/1337
> On Mon, Sep 19, 2016 at 10:52 AM Satish Duggana <[email protected]>
> wrote:
>
>> Agree with Bobby, +1 for supporting both versions till EOL and findout how
>> many users are really using 1.7.x.
>>
>> ~Satish.
>>
>>
>> On Mon, Sep 19, 2016 at 7:50 PM, Bobby Evans <[email protected]>
>> wrote:
>>
>>> I am +1 for two modules until EOL. Jan 2017. - Bobby
>>>
>>> On Saturday, September 17, 2016 4:19 AM, Jungtaek Lim <
>>> [email protected]> wrote:
>>>
>>>
>>> According to the link, last version line of ES1 (1.7.x) will be live to
>>> Jan
>>> 2017. We need to keep two versions at least EOL of that.
>>> I wouldn't mind having two modules and also wouldn't mind having
>> duplicate
>>> codes, but it would be better if we can extract common parts to parent
>>> module.
>>>
>>> Thanks,
>>> Jungtaek Lim (HeartSaVioR)
>>>
>>> 2016년 9월 16일 (금) 오후 10:03, Aaron Niskodé-Dossett <[email protected]>님이
>> 작성:
>>>
>>>> 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.
>>>>
>>>> Thanks! -Aaron
>>>>
>>>> On Thu, Sep 15, 2016 at 9:12 AM Bobby Evans
>> <[email protected]
>>>>
>>>> wrote:
>>>>
>>>>> 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 <
>>>>> [email protected]> 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,
>>>>> https://github.com/apache/storm/pull/1396
>>>>>
>>>>> 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!
>>
