Investigate scripting for configuring JRuby instances & JVM heap size at install

This ticket is related to SERVER-364 (improve max-active-instances default value) and SERVER-365 (improve heap size default value). The work in those tickets are intended to go deeper into the details of the specific algorithms that we'll use for computing the default values that should be configured for puppetserver at installation time. Ahead of finishing the details on those algorithms, we should be able to start investigating the work that will be needed in the puppetserver packaging init scripts that will be required. This ticket is intended to cover that investigation work.

Items to investigate should include:

1) Get at least a high-level understanding of how the scripting will be hooked, e.g., from Ez-Bake. This is related to EZ-31.

2) Decide upon – maybe via prototyping – best option for scripting language to be used, i.e., bash, Ruby, ...

This should take into consideration the tasks that the script will ultimately need to perform. This would include:

• Programmatic modification of the puppetserver sysconfig/default (JAVA_OPTS for heap size) and puppetserver.conf (JRuby max-active-instances).

• Gathering data that will be used in computing the desired value. This would include available system memory and the number of CPU "cores" on the local machine where puppetserver is being installed.

This should also take into account packaging implications around any upstream dependencies the script would require. For example, if we go with a Ruby script, some version of Ruby would be a dependency. If "facter" might provide the most convenient method for gathering the data needed to compute default values, it may make sense to make "facter" an upstream dependency. For programmatic manipulation of the puppetserver configuration file, it may make sense, if we choose to use Ruby, to make the Ruby HOCON gem an upstream dependency. If that proves to be too prohibitive and we decide to go with a more crude awk-like approach, the upstream dependencies may be significantly lighter.

The key deliverable from this ticket should be a detailed description of the approach that we'll use to implement SERVER-364 and SERVER-365.