Adjust JDK detection / configuration

[danielmitterdorfer]

Rally has been created before the JDK moved to a more rapid 6 month release cycle. However, meanwhile things have changed and Elasticsearch embraces this more rapid cycle. Elasticsearch allows us to set:

• RUNTIME_JAVA_HOME to define the JDK version that Elasticsearch will run with, and
• JAVA_HOME to define the JDK version that Elasticsearch is built with (will also be used if RUNTIME_JAVA_HOME is not set)

Our current configuration logic in Rally however, is still tied to specific JDK versions and we should change that. Ideally we can still figure out everything automatically for the standard case but the exact logic is yet tbd.

W.r.t. to the timeframe it would be good if we could implement this before JDK 11 is out.

[danielmitterdorfer]

After discussion we settled on the following requirements:

• We must be able to benchmark different versions of Elasticsearch which may require different JDKs to run.
• We only allow to build the master version of Elasticsearch from sources with Rally, older versions will need to be benchmarked based on a distribution (or the user can always build it outside of Rally).
• It must be possible the detection of Java version can be done non-interactively (e.g. for CI)

We came up with the following approach:

• We will add a new file java-versions.ini on top-level of the rally-teams repo. Its contents can be different per branch (which match the Elasticsearch versions). In the file we will define a property runtime.jdk which defines a comma-separated list of (major) JDK versions that are allowed with the respective Elasticsearch version. On the master branch, we will define an additional property build.jdk which defines the allowed (major) JDK version to build Elasticsearch. This property will only contain one entry.
• esrally configure will not check for Java anymore. The configuration file (in ~/.rally/rally.ini) will also not contain any Java paths anymore.
• Rally will use the environment variable JAVA_HOME to determine the home directory of the Java installation. It needs to match the following requirements:
  • For build.jdk: the major version of the Java installation JAVA_HOME points to, needs to match the required version.
  • For runtime.jdk: the major version of the Java installation JAVA_HOME points to, needs to match one of the required versions. Additionally, it must be a proper release, i.e. early access versions will be rejected (because Elasticsearch would reject them as well).
• Additionally, the user can define environment variables matching the pattern JAVAx_HOME where x is the major version, e.g. JAVA8_HOME, JAVA9_HOME, etc.. If those are defined they take precedence over JAVA_HOME. By default, Rally will pick the highest possible version that satisfies the criteria mentioned above. We will allow the user with a command line option to override that choice.

As it is possible for users to define custom team repositories, we will issue a warning if java-versions.ini is missing and rely entirely that JAVA_HOME is set to the "correct" version.

[danielmitterdorfer]

We should leverage the mechanisms introduced in #485 and define new properties in config.ini instead of a dedicated file.