[Puppet Users] Pattern for managing software versions?

On Fri, Mar 1, 2013 at 4:42 PM, Schofield wrote:

I am curious to get the opinion of the community on how people
successfully manage software versions in their puppet modules. Personally
I have adopted the profile/role pattern and have the need to support many
different combinations of java based middleware. My puppet environment has
evolved such that each major version of software gets its own class. For
example: tomcat::6_0, tomcat::7_0, java::1_6, java::1_7. The versions
then propagate into the profiles: profile::tomcat::7, profile::jboss::7,
etc. This strategy has been successful but I do see others taking
different approaches such as having a module for a single version of
software or passing in the desired version to a class as a parameter. I
haven't found any documentation or blogs that really address this so was
hoping to generate some comments on the subject with this forum post. Are
there any puppet best practices or known anti-patterns in this space?

--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, March 1, 2013 7:46:33 PM UTC-5, Brendan O'Bra wrote:
I use hiera to externalize the versions, like this:
package{'jdk':
ensure => hiera('jdk_version','present'),
require => [ YumRepo['someyumrepo'] ],
}

And then just deliver yaml based on environment/version/whatever

On Monday, March 4, 2013 10:42:32 AM UTC-6, Schofield wrote:

With this pattern, how do you handle use cases where two different
versions of the JDK are required on a node and the potential for different
configurations of the JDK such as different policy files?

If you want to be able to install multiple versions of some piece of
software, then you should obtain or create packages that allow it. For
example, RedHat-family JDK packages (java-<version>-openjdk) support this,
whereas Oracle's JDK packages for RedHat family systems do not.

On Tuesday, March 5, 2013 10:48:10 AM UTC-6, Schofield wrote:

Not really a specific problem because obviously people are successfully
using this pattern. I'm really trying to explore the difference between
the different patterns and understand why you would chose one over the
other. The current pattern that is working successfully for me is
the role/profile pattern. Here I use a profile to associate a specific jdk
version with the appserver version. It gives me one place to update the
version of the jdk for all deployments of the app server. The problem that
I can imagine (or rather what I don't fully understand yet) is how to
manage the jdk version in hiera when the jdk version is dependent on the
version of the app server and not facts on the node.