On Wednesday, July 2, 2014 5:06:46 AM UTC-5, Gavin Williams wrote: > > Morning all > > I'm currently working on a module[1] to support installation and > configuration of Apache Karaf[2], a Java OSGi container... > > I've got most of the installation piece sorted, and am starting to work on > the configuration side of things. > Unfortunately I've hit a bit of a blocker which I'm not sure of the best > way to work-around. > > As part of the service installation process, a Java wrapper config file is > created. > This config file needs to be modified to specify the 'JAVA_HOME' value. > However I'm not sure of the best way to calculate this JAVA_HOME value, due > to the variable nature of both Java variants (Java 6 vs 7, Oracle vs > OpenJDK, release version) and the fact that Java might not be installed at > the start of the Puppet run. > The intention is to use a template for the config file, so it's modifiable > by Puppet. > > Options I can think of: > > 1. Use a fact to provide JAVA_HOME. This fails if Java isn't installed > at the start of the agent run, which is a valid scenario if this module is > also installing Java... > 2. Hard code the value based on a pre-determined file path based on > chosen Java distro and version. Not very clean/configurable... > 3. Update wrapper config file to pull in system env for JAVA_HOME. > However this fails if the system version isn't the one that the app should > use... > > Am I missing a trick somewhere along the lines, or is hoping to achieve > all this - Install Java, Install Karaf, configure Karaf service - in one > run asking too much? >
Your criticisms of those options present an inconsistent view of your requirements. If the app needs to use a specific Java version that may be different from the system's default (per remarks about #3) then it's going to be pretty tricky to get the correct value from a fact, too (alternative #1). That seems to say that knowing the requisite Java version in advance (#2) is one of your requirements, so whether that's clean or configurable is irrelevant. > Thoughts/ideas welcome. > Since you are managing the Java package, in principle you can know what JAVA_HOME you will need based on which package you are ensuring installed. That is, you can know what the appropriate JAVA_HOME *will be* once Puppet is done because it is (or can be) part of what you are managing, albeit indirectly. If you want to be a little less prescriptive and a little more adaptive, at the risk of possibly needing two runs to reach a stable configuration, then you could try a combination of your alternatives 1 and 2: use a custom fact to try to choose JAVA_HOME from among those of the runtimes available before the run, and if there isn't any (or if none is suitable) then use a prediction based on knowledge of what you are about to install. Honestly, though, this seems harder and messier than my previous alternative. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/131d4f3a-df97-4ed1-b29d-322e5903d673%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
