[Puppet Users] Managing uniform package baselines (declaring *many* packages) - any tricks?

A resource can only be declared once per catalog.

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.

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