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-unsubscr...@zipkin.apache.org For additional commands, e-mail: dev-h...@zipkin.apache.org
