Puppet users - Jun 2012 - Duplicate package resource solutions?

Hi Guys,

I searched through the forum and found a few related threads but no clear 
puppet sanctioned solution. We have several modules that require the same 
package, for example rsync or gcc. We usually solve these conflicts by 
making that package a standalone module. We don''t want to have modules 
exist for the sole purpose of installing gcc. Initially we had a 
development-tools module that installed the RH equivalent of the 
"Development Tools" yum group. In some cases only a third of the
packages
were truly required, so this solution seems suboptimal.

What would be the downside of creating a module called common-packages 
which would become the central location for simple packages (no 
daemon/service, etc)? Declare all the packages within the common-packages 
class as virtual resources. Then each module can feed off that class for 
the individual packages it requires. This would solve the problem caused by 
multiple identical package resources being defined throughout modules.

class  common-packages {

    @package { "rsync":
        ensure => "present",
    }

...
}

class somemodule {
    include common-packages
    realize(Package["rsync"])

...
}

We obviously would create individual modules for packages that require any 
advanced logic: apache, tomcat, etc. What would be the downside to doing 
this?

Thanks,
Ryan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/EYtF4SJppcQJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

On 06/07/2012 06:13 AM, Ryan Bowlby wrote:
> What would be the downside of creating a module called common-packages
> which would become the central location for simple packages (no
> daemon/service, etc)? Declare all the packages within the
> common-packages class as virtual resources. Then each module can feed
> off that class for the individual packages it requires. This would solve
> the problem caused by multiple identical package resources being defined
> throughout modules.
I believe that for modules that are meant for use on your site only
(i.e. not for publishing on the forge etc.), this approach is perfectly
fine.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jun 6, 11:13 pm, Ryan Bowlby <rbowlb...@gmail.com>
wrote:
> Hi Guys,
>
> I searched through the forum and found a few related threads but no clear
> puppet sanctioned solution. We have several modules that require the same
> package, for example rsync or gcc.

Yes, this is one of the facets of the module compatibility problem.
There is no best solution.

> We usually solve these conflicts by
> making that package a standalone module.

Do you mean a class?  You shouldn''t need an entire module for each
package.

> We don''t want to have modules
> exist for the sole purpose of installing gcc. Initially we had a
> development-tools module that installed the RH equivalent of the
> "Development Tools" yum group. In some cases only a third of the
packages
> were truly required, so this solution seems suboptimal.

You could split it up into several classes, most declaring multiple
packages, each with some kind of logical consistency so that you could
pick and choose among them to tailor the config to the needs of
specific nodes.  That''s an intermediate between your first and second
options, and it could substantially reduce the installation of
unneeded packages.

> What would be the downside of creating a module called common-packages
> which would become the central location for simple packages (no
> daemon/service, etc)? Declare all the packages within the common-packages
> class as virtual resources. Then each module can feed off that class for
> the individual packages it requires. This would solve the problem caused by
> multiple identical package resources being defined throughout modules.

I don''t see much additional downside beyond what you already have.
Using virtual resources is one of the commonly recommended approaches
to this sort of module compatibility issue.  It is particularly
appropriate for Package resources, where different modules rarely have
different requirements for resource parameters.  Felix is right,
though, that class ''common-packages'' would not be suitable for
sharing, nor would modules with any explicit dependencies on that
class.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Ryan,
 
> I searched through the forum and found a few related threads but no clear 
> puppet sanctioned solution. We have several modules that require the same 
> package, for example rsync or gcc. We usually solve these conflicts by 
> making that package a standalone module. We don''t want to have
modules
> exist for the sole purpose of installing gcc. Initially we had a 
> development-tools module that installed the RH equivalent of the 
> "Development Tools" yum group. In some cases only a third of the
packages
> were truly required, so this solution seems suboptimal.
>
>
Have you taken a look at https://github.com/pdxcat/puppet-module-singleton ?

Cheers,
Paul

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/7uDzpucBFLUJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.