zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordi Polo Carres <jcar...@mdsol.com>
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
also.
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
removed.

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 <adrian.f.cole@gmail.com> 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]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dzipkin_issues_2369-23issuecomment-2D464844264&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=UGyxtS5mB-1hqFnhRydLxTnPFthNZJPG-JNtWeOfGY8&s=tNZUubhuSpaRUK46kmY9KGUxbpKilTBk1SVTQ-eO3vI&e=
> [2]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_opendistro-2Dfor-2Delasticsearch_security&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=UGyxtS5mB-1hqFnhRydLxTnPFthNZJPG-JNtWeOfGY8&s=NoOBn6nn6wfYYvlI_2ON35p01CZycE_P57SiwjQXPjY&e=
> [3]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.elastic.co_guide_en_elasticsearch_reference_7.x_breaking-2Dchanges-2D7.0.html&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=UGyxtS5mB-1hqFnhRydLxTnPFthNZJPG-JNtWeOfGY8&s=gsk8IU5eslt39FQiX5sg-Qq7r90b9hTskLYPL4L5Tug&e=
> [4]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_elastic_elasticsearch-2Dhadoop_issues_1277&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=UGyxtS5mB-1hqFnhRydLxTnPFthNZJPG-JNtWeOfGY8&s=WvGazsTiZCquaZI2YSDJt0KVh8upURR14z9njDO37as&e=
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>

-- 
*Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
<http://www.mdsol.com/>
Api bundle: api-bundle@mdsol.com
API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1

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