Here are some things I'd like to see from a new service, one which I could subclass in Java to add some specific features
- ability for service to specify preferred OS family for installation (deb, yum), maybe some other params.
- a specific preflight script that does pre-deployment checks of system (network state &c)
- explicit register_repositories script
- explicit checks for NN in the HDFS layer, JT in the MR layer, rather than just stack traces on the lookups
- make it possible to select a different set of default properties from "whirr-hadoop-default.properties";
What I'd really, really like is to be able to chain together two or more in-JAR .properties files, so that the default hadoop one was read in, then the installation specific one. This would let the vendor one provide a different set of default action (repos, scripts, default config options) that don't need to be set up correctly by everyone in their own local .properties file in order to use that installation.
The current two-level installer forces everyone to override the scripts in their target properties file, and keep in sync with any other cluster options.
Here are some things I'd like to see from a new service, one which I could subclass in Java to add some specific features
What I'd really, really like is to be able to chain together two or more in-JAR .properties files, so that the default hadoop one was read in, then the installation specific one. This would let the vendor one provide a different set of default action (repos, scripts, default config options) that don't need to be set up correctly by everyone in their own local .properties file in order to use that installation.
The current two-level installer forces everyone to override the scripts in their target properties file, and keep in sync with any other cluster options.