Too many configurations – which ones are important?
2 Configurations from 1 section and 2 from another section might be most important
No easy way to group across sections
Majority Text fields
Configs almost always shown as text fields
Can be shown in more intuitive controls
No units help
Configs might shown to user in one unit (days, GB), and be saved in a different unit (milliseconds, B)
What are acceptable values?
Open ended text fields don’t help when values have to been within a minimum/maximum values
No support for a enum of values
No configuration dependencies
After install if you change one config, you have to remember to change others
Notice that can upgrade in either same stack e.g., 2.2.*, or 2.2 -> 2.3
OpenTSDB is popular solution on top of HBASE. Time Series DB
-
Too many configurations – which ones are important?
2 Configurations from 1 section and 2 from another section might be most important
No easy way to group across sections
Majority Text fields
Configs almost always shown as text fields
Can be shown in more intuitive controls
No units help
Configs might shown to user in one unit (days, GB), and be saved in a different unit (milliseconds, B)
What are acceptable values?
Open ended text fields don’t help when values have to been within a minimum/maximum values
No support for a enum of values
No configuration dependencies
After install if you change one config, you have to remember to change others
Introduced in Ambari 1.7
Allow cluster creation or scaling to be started via the REST API prior to all/any hosts being available. As hosts register with Ambari server they will be matched to request host groups and provisioned according to the requested topology
Allow host predicates to be specified along with host count to provide more flexibility in matching hosts to host groups. This will allow for host flavors where different host groups are matched to different host flavors
Break up the current monolithic provisioning request into a request for each host operation. For example, install on host A, start on host A, install on hostB, etc. This will allow hosts to make progress even when another host encounters a failure.
Allow a host count to be specified in the cluster creation template instead of host names. This is documented in https://issues.apache.org/jira/browse/AMBARI-6275