Puppet users - Jan 2012 - How to handle multiple modules requiring the same packages

We have a database module and an application module that both require
gcc. When I include both modules in a node, I get errors about the
package being already defined.

How would I address this?

-- 
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 Fri, Jan 13, 2012 at 9:02 AM, bel <belminf@gmail.com> wrote:
> We have a database module and an application module that both require
> gcc. When I include both modules in a node, I get errors about the
> package being already defined.
>
> How would I address this?
>
>
Move the gcc package definition to a third module/class.

Tell both the db and app module that they require
Class[''gcc''].

Does that make sense?



-- 
Nigel Kersten
Product Manager, Puppet Labs

-- 
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.

It sounds like you''ve got this written down twice:

package { "gcc": ensure => installed }

Causing a duplicate resource definition. To get around this, move the 
gcc package install into a module of it''s own, called say
"gcc", then in
your database and application modules simply "include gcc" to pull in 
your new gcc module as a requirement. You will also need to look at 
requirements (http://docs.puppetlabs.com/learning/ordering.html).

If you prefer to declare your classes like this:

class { "gcc": }

Then you have to think about how to organise your node definitions a 
little bit differently as you''ll run into the same Duplicate Definition
error.

On 13/01/12 17:02, bel wrote:
> We have a database module and an application module that both require
> gcc. When I include both modules in a node, I get errors about the
> package being already defined.
>
> How would I address this?
>

-- 
Luke Bigum
Information Systems
+44 (0) 20 3192 2520
Luke.Bigum@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way. If
you are not a named recipient please notify the sender immediately and delete
any copies of this message. Any unauthorized copying, disclosure or distribution
of the material in this e-mail is strictly forbidden. Any view or opinions
presented are solely those of the author and do not necessarily represent those
of the company.

-- 
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.

Usually creating a separate class is best, but for odd single packages
I''ll add them to a single class as virtual resources.

oneoffpackages {
  @package {''mysql-client''}
  @package { ''perl-Getopt-Long-Descriptive'': }
}

Then when I want to use that package I''ll realize it.

nrpe::delllperc {
  blah blah
  realize Package[''perl-Getopt-Long-Descriptive'']
}

collectd::redis {
  blah blah
  realize Package[''perl-Getopt-Long-Descriptive'']
}

hostgroup::frontend {
  blah blah
  realize Package[''mysql-client'']
}

mysql {
  blah blah
  realize Package[''mysql-client'']

I''m not sure it''s any cleaner or easier to maintain, but
it''s another
idea.

Ramin

On Jan 13, 9:02 am, bel <belm...@gmail.com> wrote:
> We have a database module and an application module that both require
> gcc. When I include both modules in a node, I get errors about the
> package being already defined.
>
> How would I address this?
-- 
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.

You can make the package resource definition conditional.

class foo {
 if ! defined( Package[gcc] ) {
  package { gcc: ensure=>installed; }
 } 
}
class bar {
 if ! defined( Package[gcc] ) {
  package { gcc: ensure=>installed; }
 }
}

Or, define a new class for the package(s) and include that

class pkg::gcc {
  package { gcc: ensure=>installed; }
}
class foo {
include pkg::gcc
}
class bar {
include pkg::gcc
}

Second method is more elegant IMHO; but if its a one-off then first might be
simpler.

Steve

Steve Shipway
University of Auckland ITS
UNIX Systems Design Lead
s.shipway@auckland.ac.nz
Ph: +64 9 373 7599 ext 86487

-- 
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 Jan 17, 3:11 am, Steve Shipway <s.ship...@auckland.ac.nz>
wrote:
> You can make the package resource definition conditional.
>
> class foo {
>  if ! defined( Package[gcc] ) {
>   package { gcc: ensure=>installed; }
>  }}
>
> class bar {
>  if ! defined( Package[gcc] ) {
>   package { gcc: ensure=>installed; }
>  }
>
> }
>
> Or, define a new class for the package(s) and include that
>
> class pkg::gcc {
>   package { gcc: ensure=>installed; }}
>
> class foo {
> include pkg::gcc}
>
> class bar {
> include pkg::gcc
>
> }
>
> Second method is more elegant IMHO; but if its a one-off then first might
be simpler.
The first is simpler only if you get lucky, and you don''t intend to
modify your manifests ever again.  Use of the "defined" function
introduces a parse-order dependency, and the additional work you need
to do to ensure that that dependency is always fulfilled overcomes any
simplicity advantage that might otherwise exist.

If you don''t do that work, correctly, then you may still luck into the
code working, but you risk in the future making some seemingly
unrelated change that breaks it.

All-in-all, I''m inclined to consider any use whatever of the
''defined''
function to be a kludge, and a shaky one at that.


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,

On 01/17/2012 04:11 PM, jcbollinger wrote:
> The first is simpler only if you get lucky, and you don''t intend
to
> modify your manifests ever again.
basically correct, but you can even play it safe: You must make sure
each and every invocation of the resource in question is protected by
such an if defined(), ever.

Yes, it''s terrible design.

Is there a good reason that this function is even retained in recent
versions of puppet? I have yet to encounter an instance where it can be
used cleanly.

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 Jan 18, 5:52 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> Hi,
>
> On 01/17/2012 04:11 PM, jcbollinger wrote:
>
> > The first is simpler only if you get lucky, and you don''t
intend to
> > modify your manifests ever again.
>
> basically correct, but you can even play it safe: You must make sure
> each and every invocation of the resource in question is protected by
> such an if defined(), ever.

And in that case you must also make sure that the package is defined
with the same parameters everywhere, and that it stays that way.

> Yes, it''s terrible design.

Indeed.  Even for a one-off it''s more complicated to use the
conditional approach correctly than to just put the package definition
in a class.

> Is there a good reason that this function is even retained in recent
> versions of puppet? I have yet to encounter an instance where it can be
> used cleanly.

I assume the function remains for backwards compatibility.  That''s a
pretty strong motivation for keeping it, but the function could at
least be deprecated.


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.

On Wed, Jan 18, 2012 at 3:52 AM, Felix Frank <
felix.frank@alumni.tu-berlin.de> wrote:
>
> Is there a good reason that this function is even retained in recent
> versions of puppet? I have yet to encounter an instance where it can be
> used cleanly.
>
I''ll start another thread about this, but I''d quite like us to
deprecate it
for Telly.

-- 
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.

I add my 2 cents.
The alternatives proposed in the replies are ok for me, just would like to 
express an alternative approach that I''''ve used in some
situations.
It''s due to different factors:
- Many packages to manage (but not necessarily)
- Option to include a module in an existing module set, where you don''t
know if and how the packages you want to use are already defined as 
resources.
- The fact that these packages generally don''t need extra management 
(service or configuration files) and they do not harm if they are just 
installed and "forgotten" 
So the approach is to install them not as Puppet resources but via an exec:

class oracle::packages {

    require oracle::params

    file { "install_oracle_dependency.sh":
        mode    => 750, owner => root, group => root,
        content => $operatingsystem ? { 
            centos =>
template("oracle/install_oracle_dependency.sh-redhat"),
            redhat =>
template("oracle/install_oracle_dependency.sh-redhat"),
            debian =>
template("oracle/install_oracle_dependency.sh-debian"),
            ubuntu =>
template("oracle/install_oracle_dependency.sh-debian"),
            suse   =>
template("oracle/install_oracle_dependency.sh-suse"),
            },
        path    =>
"${oracle::params::workdir}/install_oracle_dependency.sh",
    }

    exec { "install_oracle_dependency.sh":
        subscribe   => File["install_oracle_dependency.sh"],
        refreshonly => true,
        timeout     => 3600,
        command     =>
"${oracle::params::workdir}/install_oracle_dependency.sh",
    }

}

where  the template install_oracle_dependency.sh-redhat is something like

#!/bin/sh
# File Managed by Puppet
# Installs the packages required for installing Oracle applications
<% if $architecture=="i386" %>
yum install -y binutils compat-db compat-libstdc++ compat-libstdc++-33
elfutils-libelf elfutils-libelf-devel elfutils-libelf-devel-static gcc gcc-c++
glibc glibc-common glibc-devel glibc-headers kernel-headers ksh libaio
libaio-devel libgcc libgomp libstdc++ libstdc++-devel make numactl-devel pdksh
sysstat unixODBC unixODBC-devel
yum groupinstall -y "X Window System"
<% else %>
yum install -y binutils compat-db compat-libstdc++ compat-libstdc++.i386
compat-libstdc++-33 compat-libstdc++-33.i386  elfutils-libelf
elfutils-libelf-devel elfutils-libelf-devel-static gcc gcc-c++ glibc glibc.i386
glibc-common glibc-devel glibc-devel.i386 glibc-headers kernel-headers ksh
libaio libaio.i386 libaio-devel libaio-devel.i386 libgcc libgcc.i386 libgomp
libstdc++ libstdc++.i386 libstdc++-devel make numactl-devel pdksh sysstat
unixODBC unixODBC.i386 unixODBC-devel.i386
yum groupinstall -y "X Window System"
<% end %>

Opinions on this approach?

al

-- 
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/-/MtdH7nObxNQJ.
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 Jan 20, 4:34 am, Alessandro Franceschi <a...@lab42.it>
wrote:
> I add my 2 cents.
> The alternatives proposed in the replies are ok for me, just would like to
> express an alternative approach that I''''ve used in some
situations.
> It''s due to different factors:
> - Many packages to manage (but not necessarily)
> - Option to include a module in an existing module set, where you
don''t
> know if and how the packages you want to use are already defined as
> resources.
> - The fact that these packages generally don''t need extra
management
> (service or configuration files) and they do not harm if they are just
> installed and "forgotten"
> So the approach is to install them not as Puppet resources but via an exec:
>
> class oracle::packages {
>
>     require oracle::params
>
>     file { "install_oracle_dependency.sh":
>         mode    => 750, owner => root, group => root,
>         content => $operatingsystem ? {
>             centos =>
template("oracle/install_oracle_dependency.sh-redhat"),
>             redhat =>
template("oracle/install_oracle_dependency.sh-redhat"),
>             debian =>
template("oracle/install_oracle_dependency.sh-debian"),
>             ubuntu =>
template("oracle/install_oracle_dependency.sh-debian"),
>             suse   =>
template("oracle/install_oracle_dependency.sh-suse"),
>             },
>         path    =>
"${oracle::params::workdir}/install_oracle_dependency.sh",
>     }
>
>     exec { "install_oracle_dependency.sh":
>         subscribe   => File["install_oracle_dependency.sh"],
>         refreshonly => true,
>         timeout     => 3600,
>         command     =>
"${oracle::params::workdir}/install_oracle_dependency.sh",
>     }
>
> }
>
> where  the template install_oracle_dependency.sh-redhat is something like
>
> #!/bin/sh
> # File Managed by Puppet
> # Installs the packages required for installing Oracle applications
> <% if $architecture=="i386" %>
> yum install -y binutils compat-db compat-libstdc++ compat-libstdc++-33
elfutils-libelf elfutils-libelf-devel elfutils-libelf-devel-static gcc gcc-c++
glibc glibc-common glibc-devel glibc-headers kernel-headers ksh libaio
libaio-devel libgcc libgomp libstdc++ libstdc++-devel make numactl-devel pdksh
sysstat unixODBC unixODBC-devel
> yum groupinstall -y "X Window System"
> <% else %>
> yum install -y binutils compat-db compat-libstdc++ compat-libstdc++.i386
compat-libstdc++-33 compat-libstdc++-33.i386  elfutils-libelf
elfutils-libelf-devel elfutils-libelf-devel-static gcc gcc-c++ glibc glibc.i386
glibc-common glibc-devel glibc-devel.i386 glibc-headers kernel-headers ksh
libaio libaio.i386 libaio-devel libaio-devel.i386 libgcc libgcc.i386 libgomp
libstdc++ libstdc++.i386 libstdc++-devel make numactl-devel pdksh sysstat
unixODBC unixODBC.i386 unixODBC-devel.i386
> yum groupinstall -y "X Window System"
> <% end %>
>
> Opinions on this approach?

1) Many of the packages you mention are pretty fundamental.  If you
want to manage them then it would be better to group them into a
module for your standard environment, instead of allowing various
other modules to manage them.

2) It would be better to let the package management system handle
finding and installing depenencies.  Where the software you want to
install is not available pre-packaged and cannot easily be packaged
locally, it would still be better to build a requirements-only package
(e.g. "oracle-dependencies") and manage that.

3) If you want to name the packages explicitly in your Puppet
configuration, then it would be better to declare them in some central
place as virtual Package resources.  Modules that want them would then
*realize* them instead of declaring them.  It is not a problem for a
virtual resource to be realized many times for the same node.


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.

I find it confusing that Puppet defines modules as reusable code yet,
when it comes to packages, you have to have prior knowledge of what
other package resources are defined.

Thank you for all the proposed solutions but does anyone know if
Puppet has a best practice they recommend in this case? Otherwise, I''m
going with defining new classes for the packages.

On Jan 17, 4:11 am, Steve Shipway <s.ship...@auckland.ac.nz>
wrote:
> You can make the package resource definition conditional.
>
> class foo {
>  if ! defined( Package[gcc] ) {
>   package { gcc: ensure=>installed; }
>  }}
>
> class bar {
>  if ! defined( Package[gcc] ) {
>   package { gcc: ensure=>installed; }
>  }
>
> }
>
> Or, define a new class for the package(s) and include that
>
> class pkg::gcc {
>   package { gcc: ensure=>installed; }}
>
> class foo {
> include pkg::gcc}
>
> class bar {
> include pkg::gcc
>
> }
>
> Second method is more elegant IMHO; but if its a one-off then first might
be simpler.
>
> Steve
>
> Steve Shipway
> University of Auckland ITS
> UNIX Systems Design Lead
> s.ship...@auckland.ac.nz
> Ph: +64 9 373 7599 ext 86487
-- 
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.