FAQ
Hello,
Our group is currently moving from RHEL5 and an in-house baseline
management system and yum repositories to RHEL6, Puppet , and RHN Satellite.

With our old homebrew management framework we had a lot of flexibility and
ease in declaring which packages should be allowed or disallowed, defined
either by-system or by-class/role of system.

A couple examples:

In Joe's server definition file:
install - tomcat, java17-oracle, httpd, tomcat, confluence
uninstall - java16-sun

Or 'class development workstation':
install - hg, git, subversion, eclipse, vim, ...(tens or hundreds of RPMs)
uninstall - rcs, emacs



Now for puppet it seems you can only declare/manage a package resource in 1
place across all of puppet, so the only semi-viable way to manage package
baselines so far is to make a module for each RPM we care about managing,
then add those modules to node definitions or to classes, since you can
include a module many times and it doesn't mind.

An example would now be:

manifests/nodes/joe_ws.domain.tld/node.pp:
include development_workstation

And in manifests/classes/development_workstation/init.pp
include mercurial
include git
include subversion
include eclipse
include vim


I kind of feel like I'm doing things in a more complicated way than I need
to, but I'm not sure how to simplify - so I ask the more experienced puppet
peeps out there, how are you managing software baselines?

Thanks!

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

  • Llowder at Apr 15, 2013 at 2:40 pm

    On Monday, April 15, 2013 9:13:27 AM UTC-5, Kodiak Firesmith wrote:
    Hello,
    Our group is currently moving from RHEL5 and an in-house baseline
    management system and yum repositories to RHEL6, Puppet , and RHN Satellite.

    With our old homebrew management framework we had a lot of flexibility and
    ease in declaring which packages should be allowed or disallowed, defined
    either by-system or by-class/role of system.

    A couple examples:

    In Joe's server definition file:
    install - tomcat, java17-oracle, httpd, tomcat, confluence
    uninstall - java16-sun

    Or 'class development workstation':
    install - hg, git, subversion, eclipse, vim, ...(tens or hundreds of
    RPMs)
    uninstall - rcs, emacs



    Now for puppet it seems you can only declare/manage a package resource in
    1 place across all of puppet, so the only semi-viable way to manage package
    baselines so far is to make a module for each RPM we care about managing,
    then add those modules to node definitions or to classes, since you can
    include a module many times and it doesn't mind.
    A resource can only be declared once per catalog.

    An example would now be:

    manifests/nodes/joe_ws.domain.tld/node.pp:
    include development_workstation

    And in manifests/classes/development_workstation/init.pp
    include mercurial
    include git
    include subversion
    include eclipse
    include vim


    I kind of feel like I'm doing things in a more complicated way than I need
    to, but I'm not sure how to simplify - so I ask the more experienced puppet
    peeps out there, how are you managing software baselines?
    We have a module called "basenode" which handles the things that are common
    across *all* nodes (7zip, ntp, puppet etc).

    Some of these are given their own module (puppet, ntp, apt) and others just
    get a package resource (7zip).

    For things that are on *most* nodes but not all, I create a hash of hashes
    in my common.yaml, then override as needed in more specific yaml files.

    Then I just use a create_resources() call and feed it the hash of hashes -
    but this is only for things that don't require configuration and simply
    need the package to be installed. If it needs a config file customized,
    then it goes into its own module.

    There are other ways to handle this, and some may be better (or just better
    in specific cases) but this works for us.


    Thanks!
    --
    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 Apr 16, 2013 at 2:32 pm

    On Monday, April 15, 2013 9:13:27 AM UTC-5, Kodiak Firesmith wrote:
    Hello,
    Our group is currently moving from RHEL5 and an in-house baseline
    management system and yum repositories to RHEL6, Puppet , and RHN Satellite.

    With our old homebrew management framework we had a lot of flexibility and
    ease in declaring which packages should be allowed or disallowed, defined
    either by-system or by-class/role of system.

    A couple examples:

    In Joe's server definition file:
    install - tomcat, java17-oracle, httpd, tomcat, confluence
    uninstall - java16-sun

    Or 'class development workstation':
    install - hg, git, subversion, eclipse, vim, ...(tens or hundreds of
    RPMs)
    uninstall - rcs, emacs



    Now for puppet it seems you can only declare/manage a package resource in
    1 place across all of puppet, so the only semi-viable way to manage package
    baselines so far is to make a module for each RPM we care about managing,
    then add those modules to node definitions or to classes, since you can
    include a module many times and it doesn't mind.

    That's not exactly true. You may not declare any given resource more than
    once for any particular node, but you may choose among alternative
    declarations. Also, you can use virtual resources to separate declaration
    of a resource's parameters from the decision of whether to actually manage
    the resource on the target node. And there are ways to override the
    parameters (including 'ensure') of a resource declared somewhere else.

    If your main objective is to be able to associate particular packages with
    the target node from more than one place, then virtual resources will be
    much lighter-weight than creating a separate class for each package.
    Example:

    class site::all_packages {
    # declare all packages we care about for any node,
    # virtually

    @package {
    'emacs': ensure => 'latest';
    'git': ensure => 'latest';
    'mercurial': ensure => 'latest';
    'rcs': ensure => 'latest';
    'vim': ensure => 'latest';
    # ...
    }
    }

    class site::development_workstation {
    include 'site::all_packages'

    # These classes may be realized any number of times:
    realize Package['git', 'mercurial', 'vim']

    # This form does the same thing as the above:
    Package<| title == 'vim' |>

    # But the collection version allows parameter override, too:
    Package<| title == 'emacs' |> {
    ensure => 'absent'
    }
    }

    You can also use subclasses of a package's declaring class
    (site::all_packages in the example) to override its parameters. Parameter
    overrides are the key function of class inheritance in Puppet, in fact.
    Subclassing has fallen somewhat out of favor in Puppet lately, owing in
    large part to hiera's rise to prominence, but it may still fit well in the
    context of applying customizations to a common baseline configuration.

    There are several variations and alternative approaches, too. For example,
    you could explicitly tag your package declarations with keys identifying
    the node roles for which those packages are wanted, then collect them by
    tag, like so:

    Package<| tag == 'development_workstation' |>

    Or there are several ways to apply hiera to the problem, whether by
    recording whole package declarations to be loaded via hiera and actualized
    via create_resources(), or simply by recording arrays of the names of
    virtual packages to realize.

    Consider also what level of granularity is best in any particular area.
    The idea of a separate class for each package, for instance, ignores the
    likelihood that you have groups of packages that you will always want to
    manage as a unit. Do approach manifest design as a modeling problem, as
    opposed to a programming problem.

    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
postedApr 15, '13 at 2:13p
activeApr 16, '13 at 2:32p
posts3
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase