Single runtime configuration file with easy overrides

[lukas-vlcek]

Me and @unibrew were discussing configuration of Searchisko more and our discussion led me to opening this ticket for which I would like to get more feedback from whole team.

Current state

We need to clearly distinguish between configuration that is pushed into Searchisko after it is started and runtime configuration that must be in place before Searchisko is started. For the former we created a separate repo (see #71) and the later currently spread across several properties files repeated in several profiles (which itself is cause of issues like #235). Also in some cases configuration values are in pom.xml file.

The goals

• Simplification of runtime configuration
• Support all deployment scenarios we use today (localhost, OpenShift, RPM ...)
• Make it easy for developers to keep and maintain custom runtime configuration without getting into VCS conflicts

Proposal

• Let's have only a single configuration file for all runtime aspects of Searchisko. It can be called searchisko.properties.
• This file will be result of merging of all existing properties files (per profile), because of this we will introduce "namespaces" for each variable. For example we now have cluster.name variable for both the search cluster and stats cluster. It will become stats.cluster.name and search.cluster.name.

Searchisko configuration will be used as follows:

1. At startup, Searchisko will check if there is any ENV variable that specify location of the configuration file (i.e. searchisko.config=~/test/searchisko.properties). If there is, then the configuration file will be loaded from this location, otherwise it will be loaded from default location (e.g classpath?)
2. Searchisko will create (singleton) instance of Configuration object (having Map like interface) that will be used to access all configuration variables.
3. When asked about particular variable value the Configuration object will:
   1. check if there is ENV variable defined for this namespace, if yes, it will return this value
   2. check if there was value provided for this namespace in configuration file, if yes, it will return this value
   3. will return optional value provided by client when Configuration object was ask about it (so the contract would be like: configuration.get("search.cluster.name", "musketeers");)
   4. will throw RuntimeException

Questions

• Does it make sense to use different format for the configuration file, like JSON instead of Properties file? The advantage of JSON over Properties file is that it supports arrays natively.