You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zipkin.apache.org by Adrian Cole <ad...@gmail.com> on 2019/04/22 00:14:25 UTC
Elasticsearch and versions
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://github.com/apache/incubator-zipkin/issues/2369#issuecomment-464844264
[2] https://github.com/opendistro-for-elasticsearch/security
[3] https://www.elastic.co/guide/en/elasticsearch/reference/7.x/breaking-changes-7.0.html
[4] https://github.com/elastic/elasticsearch-hadoop/issues/1277
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org
Re: Elasticsearch and versions
Posted by Jordi Polo Carres <jc...@mdsol.com>.
Sounds good to me!
On Thu, May 2, 2019, 7:32 AM Adrian Cole <ad...@apache.org> wrote:
> I've added the following note to our pending release notes on 2.13. Feel
> free to revise them!
>
> Note on Elasticsearch support
>
> Elastic's current support policy is latest major version (currently 7) and
> last minor (currently 6.7). This limits our ability to support you. For
> example, Elasticsearch's hadoop library is currently broken for versions
> 2.x and 5.x making our dependencies job unable to work on that range and
> also work on version 7.x.
>
> Our next release will support Elasticsearch 7.x, but we have to drop
> Elasticsearch 2.x support. Elasticsearch 5.x will be best efforts. We
> advise users to be current with Elastic's supported version policy, to
> avoid being unable to upgrade Zipkin.
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dzipkin_releases_tag_v2.13.0&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=zQCEZgyTbliBFeu5WLbItooxCeUTBQ7UnlU4DlSNE8U&s=q4FlowvLmzu6K9V8WovDm6isubZLSOAGSbvwCQwqubU&e=
>
> On 2019/04/27 00:03:17, Adrian Cole <ad...@gmail.com> wrote:
> > > What's the best way of communicating timelines of support?
> >
> > I think we can use the following, but most important is the release notes
> > * release notes
> > * clarification in the README
> > * note in LastMonthInZipkin
> > * tweet
> > * email the the not quite defunct old user mailing list
> >
> > sg?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> > For additional commands, e-mail: dev-help@zipkin.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>
Re: Elasticsearch and versions
Posted by Adrian Cole <ad...@apache.org>.
I've added the following note to our pending release notes on 2.13. Feel free to revise them!
Note on Elasticsearch support
Elastic's current support policy is latest major version (currently 7) and last minor (currently 6.7). This limits our ability to support you. For example, Elasticsearch's hadoop library is currently broken for versions 2.x and 5.x making our dependencies job unable to work on that range and also work on version 7.x.
Our next release will support Elasticsearch 7.x, but we have to drop Elasticsearch 2.x support. Elasticsearch 5.x will be best efforts. We advise users to be current with Elastic's supported version policy, to avoid being unable to upgrade Zipkin.
https://github.com/apache/incubator-zipkin/releases/tag/v2.13.0
On 2019/04/27 00:03:17, Adrian Cole <ad...@gmail.com> wrote:
> > What's the best way of communicating timelines of support?
>
> I think we can use the following, but most important is the release notes
> * release notes
> * clarification in the README
> * note in LastMonthInZipkin
> * tweet
> * email the the not quite defunct old user mailing list
>
> sg?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org
Re: Elasticsearch and versions
Posted by Adrian Cole <ad...@gmail.com>.
> What's the best way of communicating timelines of support?
I think we can use the following, but most important is the release notes
* release notes
* clarification in the README
* note in LastMonthInZipkin
* tweet
* email the the not quite defunct old user mailing list
sg?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org
Re: Elasticsearch and versions
Posted by Jordi Polo Carres <jc...@mdsol.com>.
What's the best way of communicating timelines of support?
On Thu, Apr 25, 2019, 7:24 PM Adrian Cole <ad...@gmail.com> wrote:
> On Fri, Apr 26, 2019 at 11:21 AM Jordi Polo Carres <jc...@mdsol.com>
> wrote:
> >
> > 2.x was eol one year ago. I think it is fair to drop it.
> >
> > 5.x was eol 1 month ago. Maybe give it 6 more months?
> >
> > ES deprecate versions every year or so. Fast for many enterprise
> > environment
>
> Sounds OK, but we haven't given any notice at all, so the next release
> should maintain 2.x and then we can drop it after mentioning this.
>
> NOTE: to not repeat the problems of others, we should treat this as a
> soft policy until more end users know what's going on. If we end up
> deciding something based on a couple people in an email exchange, we
> aren't much better than the situation that led to this thread.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>
Re: Elasticsearch and versions
Posted by Adrian Cole <ad...@gmail.com>.
On Fri, Apr 26, 2019 at 11:21 AM Jordi Polo Carres <jc...@mdsol.com> wrote:
>
> 2.x was eol one year ago. I think it is fair to drop it.
>
> 5.x was eol 1 month ago. Maybe give it 6 more months?
>
> ES deprecate versions every year or so. Fast for many enterprise
> environment
Sounds OK, but we haven't given any notice at all, so the next release
should maintain 2.x and then we can drop it after mentioning this.
NOTE: to not repeat the problems of others, we should treat this as a
soft policy until more end users know what's going on. If we end up
deciding something based on a couple people in an email exchange, we
aren't much better than the situation that led to this thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org
Re: Elasticsearch and versions
Posted by Jordi Polo Carres <jc...@mdsol.com>.
2.x was eol one year ago. I think it is fair to drop it.
5.x was eol 1 month ago. Maybe give it 6 more months?
ES deprecate versions every year or so. Fast for many enterprise
environment
On Mon, Apr 22, 2019, 3:50 PM Adrian Cole <ad...@gmail.com> wrote:
> To put things in perspective about the upgrade concern and libraries. It is
> very often the case that when using elastic's hadoop library, supporting
> most recent Elasticsearch requires immediate upgrade. This means a release
> of the job.
>
> That part is not so much the problem expect in the issue mentioned above
> doing that for ES 7 (which we are nagged constantly about) breaks 2.x and
> also 5.x.
>
> To support the few on 7 will break probably a lot.. who knows how many.. on
> 5. Ideally ES will have integration tests like we do to know when things
> break but this has not occurred yet and literally the answer I was given
> was that the policy will be current major and last minor.
>
> IOTW not immediately upgrading to ES libraries will have an effect which is
> more angry people like we have now spamming our issues list about most
> recent ES version.
>
> At least the main repo we are insulated as we have our own client library,
> so we dont break as often as upstream. However, dependencies suddenly not
> working will be a problem. To your point though.. we could make a matrix on
> the last version you can use for what ES version. Bugs in the dependencies
> jobs are less critical than the server.
>
> So, maybe this is the best path for now? Keep a matrix on the dependencies
> (spark) job?
>
> -A
>
Re: Elasticsearch and versions
Posted by Adrian Cole <ad...@gmail.com>.
To put things in perspective about the upgrade concern and libraries. It is
very often the case that when using elastic's hadoop library, supporting
most recent Elasticsearch requires immediate upgrade. This means a release
of the job.
That part is not so much the problem expect in the issue mentioned above
doing that for ES 7 (which we are nagged constantly about) breaks 2.x and
also 5.x.
To support the few on 7 will break probably a lot.. who knows how many.. on
5. Ideally ES will have integration tests like we do to know when things
break but this has not occurred yet and literally the answer I was given
was that the policy will be current major and last minor.
IOTW not immediately upgrading to ES libraries will have an effect which is
more angry people like we have now spamming our issues list about most
recent ES version.
At least the main repo we are insulated as we have our own client library,
so we dont break as often as upstream. However, dependencies suddenly not
working will be a problem. To your point though.. we could make a matrix on
the last version you can use for what ES version. Bugs in the dependencies
jobs are less critical than the server.
So, maybe this is the best path for now? Keep a matrix on the dependencies
(spark) job?
-A
Re: Elasticsearch and versions
Posted by Adrian Cole <ad...@gmail.com>.
thanks for the feedback, Jordi. I think one point you mention is a bit of
whistling past the graveyard though.
> People can stay in older Zipkin versions till they migrate. > Is not like
we
> break their current installation.
many people historically, even you personally, have asked for extremely
high care when we do anything related to storage. it sounds like what you
are saying is that it is ok to drop support for whatever storage concerns
arise, as long as it wasnt our direct cause.
do you really think users will split hairs like this? we are often prey to
support questions regardless of root cause. having our users not upgrade
zipkin also causes huge support burden. it is hard enough to get people to
upgrade as it is. remember the talks about previous ES versions?
I'm not saying we have much better choice but I also think aggressive
version policy on storage will hurt especially those on the gitter support
channel.. explaining why dependencies doesnt work anymore for example.
Re: Elasticsearch and versions
Posted by Jordi Polo Carres <jc...@mdsol.com>.
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 <ad...@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