zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordi Polo Carres <>
Subject Re: Elasticsearch and versions
Date Mon, 22 Apr 2019 16:33:54 GMT
I think it is fair for Zipkin to deprecate a DB which upstream deprecates
It is not the Zipkin project to blame for this policy or the speed at which
these changes happen.

I do not think we need to remove support as soon as they deprecate though
(no PR just to remove) but if a PR or a new functionality is stuck because
of work needed for compatibility on a deprecated version, at that point is

People can stay in older Zipkin versions till they migrate. Is not like we
break their current installation.

Also, in general I think people use traces info as perishable data. I guess
for many parties dropping the current data and gathering traces again is
good enough and that should make transition easier.

On Sun, Apr 21, 2019 at 5:14 PM Adrian Cole <> wrote:

> 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.
> Thoughts?
> -A
> [1]
> [2]
> [3]
> [4]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

*Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
Api bundle:
API standard:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message