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+unsubscr...@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.
