Duplicate package resource solutions?

[Ryan Bowlby]

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

[Felix Frank]

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

[jcbollinger]

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

[Paul Tötterman]

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