Puppet users - Mar 2013 - Pattern for managing software versions?

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

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 Fri, Mar 1, 2013 at 4:42 PM, Schofield <dbschofield@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
GVoice: 707.410.0371
LinkedIn: http://www.linkedin.com/in/brendanobra

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

+1 for Brendan''s technique. This is the precisely the same technique
that I
use/recommend when working with customers.

FWIW, keep an eye on the Puppet Labs site. We have someone working on a
raft of Puppet "best practices" documents and I expect that they
should
start landing soon. I''m certain that effective use of Hiera will be a
topic
of focus.

-- 
---
Nathan Valentine - nathan@puppetlabs.com
Puppet Labs Professional Services
GV: 415.504.2173
Skype: nrvale0

-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
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
>
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? 

-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
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 Monday, March 4, 2013 10:42:32 AM UTC-6, Schofield
wrote:
>
>
>
> 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
>>
>
> 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.

Configuration files are a separate question, but I don''t see why your 
scenario would constitute a special case for them.  Do you imagine a 
specific problem in that area?


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

>
> 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.
>
 
Agreed, had to repackage the oracle JDK''s to play nice:)
 
> Configuration files are a separate question, but I don''t see why
your
> scenario would constitute a special case for them.  Do you imagine a 
> specific problem in that area?
>
 
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.

-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
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 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.
>
Much depends on the details, but if the JDK version required is a function 
of the app server version, then the structure or arrangement of your hiera 
data should reflect that.  There are many ways to do it; here''s one of
them:

data
----
server_version_to_jdk_version:
  1.0: 5.0
  2.0: 6.0
  2.5: 7.0


manifest
----
$server_to_jdk_table = hiera(''server_version_to_jdk_version'')
$jdk_version = $server_to_jdk_table[$appserver_version]


I think you can also define hierarchy levels based on %{} interpolated 
variables that are not node facts, as long as they are in-scope at the 
point where you perform the lookup.  Depending on how your classes are set 
up, you might also be able to make use of %{calling_class}.


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