Puppet users - Apr 2013 - Managing uniform package baselines (declaring *many* packages) - any tricks?

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.

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.

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.