metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Elliston Ball <>
Subject Re: [DISCUSS] Dropping support for elastic 2.x
Date Wed, 04 Oct 2017 17:07:29 GMT
The simplest option would probably be to upgrade the ES and then reindex from the HDFS store.
Alternatively there are means to do inplace upgrades from 2.x to 5.x I believe. 


> On 4 Oct 2017, at 18:05, Casey Stella <> wrote:
> So, how would this work in an upgrade scenario that does not involve losing
> the existing indexed data?
> On Wed, Oct 4, 2017 at 12:55 PM, Michael Miklavcic <
>> wrote:
>> The client I'm currently working on moving towards would *not* be backwards
>> compatible.
>> rest/current/java-rest-high-compatibility.html
>> "
>> The High Level Client is guaranteed to be able to communicate with any
>> Elasticsearch node running on the same major version and greater or equal
>> minor version. It doesn’t need to be in the same minor version as the
>> Elasticsearch nodes it communicates with, as it is forward compatible
>> meaning that it supports communicating with later versions of Elasticsearch
>> than the one it was developed for.
>> The 5.6 client can communicate with any 5.6.x Elasticsearch node. Previous
>> 5.x minor versions like 5.5.x, 5.4.x etc. are not (fully) supported.
>> "
>> Best,
>> Mike
>> On Wed, Oct 4, 2017 at 10:45 AM, Simon Elliston Ball <
>>> wrote:
>>> A number of people are currently working on upgrading the ES support in
>>> Metron to 5.x (including the clients, and the mpack managed install).
>>> Would anyone have any objections to dropping formal support for 2.x as a
>>> result of this work? In theory the clients should be backward compatible
>>> against older data stores, so metron could be upgraded without needing an
>>> elastic upgrade.
>>> In practice, we would need to do pretty extensive testing and I wouldn’t
>>> want us to have to code around long term support on older clients if
>> no-one
>>> in the community cares enough about the older ES. Do we think there is a
>>> case to be made for maintaining long term support for older clients?
>>> Simon

View raw message