FAQ
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.

Search Discussions

  • Brendan O'Bra at Mar 2, 2013 at 12:46 am
    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 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.
  • Nathan Valentine at Mar 2, 2013 at 11:25 pm
    +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.
  • Schofield at Mar 4, 2013 at 4:42 pm

    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.
  • Jcbollinger at Mar 4, 2013 at 10:46 pm

    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.
  • Schofield at Mar 5, 2013 at 4:48 pm

    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.
  • Jcbollinger at Mar 6, 2013 at 2:31 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMar 2, '13 at 12:42a
activeMar 6, '13 at 2:31p
posts7
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase