Does all features of Rally work with Elasticsearch 2.3.x or 5.0.0 is the minimum ES version for rally?
I could not find anything related to this in the doc.
Disclaimer: I am the main author of Rally.
The earliest version that works with Rally is Elasticsearch 1.7 (actually, even earlier 1.x versions should work). These features will not work with earlier versions of Elasticsearch:
Benchmarking with plugins works only with 5.x or later: As you might have noted, you can have Rally set up the cluster for you before benchmark or you can use Rally just as a load generator and set up the cluster yourself. In the latter case, you can install plugins on older cluster versions as you see fit and use Rally to generate load. It's just that you cannot use Rally to set up the cluster for you in that case.
Benchmarking source builds works only with 5.x or later: The reason is that Elasticsearch has switched from Maven to Gradle as a build tool with 5.0 and there is no point in supporting two build tools.
In general, there is not much code in Rally that is depending on the version of Elasticsearch. This is rather covered in tracks and cars (see https://github.com/elastic/rally-tracks and https://github.com/elastic/rally-teams respectively) which use dedicated git branches to account for differences between Elasticsearch versions.
Having that said, Elasticsearch 1.x is end of life since January 2017 and in the interest of maintainability, Rally will drop support for older versions of Elasticsearch at some point. However, as long as it is feasible, I want to keep it around.
Related
How can I download the user docs/documentation/manual for older ElasticSearch for offline usage?
Recently, the online documentation for older versions of ElasticSearch (for example, ElasticSearch 1.3.2) started to show this message:
WARNING: Version 1.3 of Elasticsearch has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
What worries me most is the may be removed part. Right now, we don't have the resources to upgrade our software to support the latest ElasticSearch version, so we will need to keep working with the older versions for a while. How I will be able to give maintenance to our software if the Elastic company decides to remove the documentation for older versions of ElasticSearch? There is any way to download it from https://www.elastic.co/ or build it from some repository?
Thank you very much for your help!
You can clone the official elasticsearch repository to a local machine, change to branch to the version you want, in your cause branch 1.3, then you will have the documentation in the directory docs.
The documentation is in the .asciidoc format, you can try build it following the official instructions, or using other asciidoc to pdf/html converters.
How do I get the measures (like code-coverage, technical debt, complexity, nloc, ...) of a certain build version (eg. 1.0.0.20) from the api of SonarQube?
My goal is to get these information and display it along with some-other info pertaining to that version got from other sources like bitbucket.
I am able to only see the measures of the current (latest) build (eg. 1.0.0.45) version through the api/measure/component api link.
Although, I can see these measures for individual builds through the UI under the compare option. But how to get it through rest api?
SonarQube Version 5.5
Plugins:
sonar-scoverage-plugin-5.1.3.jar
sonar-scm-git-plugin-1.2.jar
sonar-scalastyle-plugin-0.0.1-SNAPSHOT.jar
sonar-javascript-plugin-2.11.jar
First of all, SonarQube 5.5 is old, you should first consider using the latest LTS (5.6) in order to be able to get feedbacks.
Versions of projects can be found by using :
api/events/index (it's replaced by api/project_analyses/search in 6.3) -> it will return you the date of analysis on which there's a version.
And in order to get measures from the past, you can use :
api/timemachine/index (it's replaced by api/measures/search_history
in 6.3) -> you'll be able to found the measures from the version you want.
I have questions concerning cdh and how it is maintained:
when I go to the packaging info related to a specific cdh version, I can check the package version of each component (for instance for cdh 5.5.5 : https://www.cloudera.com/documentation/enterprise/release-notes/topics/cdh_vd_cdh_package_tarball_55.html#cdh_555 ). However I don't understand what does the "package version" refers to exactly. For instance, for the component Apache Parquet, the "package version" is parquet-1.5.0+cdh5.5.5+181 . How can I find out exactly what source code is packaged ? Does this correspond to a label on a specific repo? If I go to the "official" apache parquet repo, there is no "cdh5.5.5" branch, the closest thing I have is a tag called "1.5.0" ( https://github.com/apache/parquet-mr/tree/parquet-1.5.0 ) . How do the people from cdh know what parquet-1.5.0+cdh5.5.5+181 exactly refers to ?
Still concerning Apache Parquet, how come even the most recent cdh versions are still using the Apache Parquet on tag is 22 May 2014, ie more than 3 years ago. Why don't they upgrade to a newer version, like 1.6.0 ? The reason I'm asking is that there is a bug in 1.5.0 that was fixed more than 3 years ago in parquet 1.6.0, yet the latest cdh version is still using the 1.5.0 version. Is there a reason why they keep using a really old, bugged, version?
thanks !
You are correct in assuming parquet-1.5.0+cdh5.5.5+181 is closest to parquet 1.5.0. However the code will not be identical to parquet 1.5.0
upstream because:
CDH enforces cross component compatibility. Code and applications using parquet-1.5.0 must also work with all the other Hadoop services (HDFS, Hive, Oozie, YARN, Spark, Solr, HBase). Incompatibilities would have to be fixed so parquet's code would include those bug fixes.
CDH enforces major version compatibility. This means an application written on CDH5.1 should still work on CDH5.5 and CDH5.7, all CDH5.x versions. This also would alter the codebase.
The best way to interpret this is to say that parquet-1.5.0+cdh5.5.5+181 will support all features provided in parquet 1.5.0 and will also work with the corresponding Hadoop services packaged with CDH5.5.
Version compatibility is also the reason why CDH Hadoop service versions run older versions of the related upstream projects. It's much harder to maintain backwards compatibility especially if APIs change between versions.
I'm looking to upgrade my Elasticsearch cluster to 1.4.5 or 1.5 and was curious if this upgrade will break my current codebase.
We are using NEST 1.3.1 in our code and I want to see if this version supports Elasticsearch 1.4.5 and higher? If you could link some documentation regarding this support, that would help me tremendously. Thank you all!
Did you consider upgrading Nest? Within the same major version, it is pretty much always backward compatible. With an older version of Nest and newer version of Elasticsearch, you would miss out on being able to use any new features that the newer version of Elasticsearch may provide. Anyways, you can read about the release notes of Nest here.
I am currently using NEST v1.0.2 with elasticsearch v1.3.2. I would like to upgrade elasticsearch to 1.4 without having to change my application's NEST dependencies, but I am having trouble finding any information about compatibility of the client APIs with more mature versions of elasticsearch. Does anyone know if these two different versions of the products will be compatible?
For the most part, yes, but it isn't recommended. Any 1.x version of NEST should, in theory, be compatible with any 1.x version of Elasticsearch. However, we don't guarantee this as we do not continually test older versions of the client against newer versions of Elasticsearch. Any breaking change introduced in Elasticsearch may break the client as well.
However, we do guarantee backwards compatibility between minor versions of NEST. So upgrading to NEST 1.4 will not break anything in your application, and would also allow you to take advantage of all the new Elasticsearch 1.4 features.
I highly recommend upgrading to NEST 1.4 as well.