zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <>
Subject Elasticsearch and versions
Date Mon, 22 Apr 2019 00:14:25 GMT
Hi, team.

There have been some interesting turns in Elasticsearch, and some
things that have always been around. TL;DR; we are being forced into a
corner where we have to immediately inherit Elastic the company's
version policy, and we need to figure out what to do about that.

## Licensed features people rely on
Elasticsearch has non-ASL code in their distribution for
authentication (X-Pack), and recently solved index load problems also
not in ASL [1]. Amazon is starting to address some of this in a fully
ASL different distribution, called OpenDistro [2]. Meanwhile, we have
significant problems due to performance. Elastic's "Basic Licensing"
may be ok for some sites, but it is also not ASL so difficult to
reason with.

## Constant upgrade burden, and fast deprecation
There have been significant problems caused on upgrade paths. Most
recently, ES changed their index naming convention, but also changed
the index template too [3]. Even with Phillip's help discussing the
problems, the ES community doesn't revert the most breaking changes..
IOTW, we get morale support and guidance, but changes made by a few
people at Elastic burden us. This burden is increased as now, their
version policy is to support only the latest version and last minor.
For example, if everything breaks in 7, there's only one version
people can use.. the last version of 6 [4]

## What to do about this?
Elasticsearch is helpful in its own ecosystem, especially kibana, but
we seem to be at a crossroads for how to support our own ecosystems.
While it might be fine to dump ES 2.x support, it is probably hard to
ask people to immediately dump ES 5.x just because Elastic the company
released ES 7. If we revlock to Elastic the company's change policies,
I think users will just stop upgrading. However, I don't think we have
many choices but to follow their policy lock-step or, like we do with
mysql -> mariadb, pick a different distribution based on friendlier
license etc. OpenDistro is the only I know of, and not only is this a
new product, but it also only has ES 6.x at the moment.

If we adopt Elastic the company's policy lockstep, I think our first
apache release we "may" be able to still support the current version
range, but it largely depends on what's accepted in their hadoop
library [4]. We may still be able to hack by shading an entire library
tree just for ES 2.x..

Regardless, we should warn the community that it may not be possible
for us to support the dependencies job, if not ES itself, more than
Elastic the company's policy.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message