How to handle multiple definitions of the same package in multiple included modules?

[EmmEff]

How to handle this scenario?

Assume that all three apps are defined in three separate modules.  All three modules are mutually exclusive with the exception that they require the same packageA to be installed.

Pseudocode:

class module1::app1 {

  package {

    'packageA':

      ;

  }

}

class module2::app2 {

  package {

    'packageA':

      ;

  }

}

class module3::app3 {

  package {

    'packageA':

      ;

  }

}

-- site.pp

node 'mynode.example.com' {

  include module1::app1

  include module2::app2

  include module3::app3

}

This will give me an error that packageA is already defined in another file.  I *know* I'm missing something simple, but what is it?  How can I avoid this situation of the duplicate package definitions while ensuring the resource Package['packageA'] is created?

I tried the following but I guess I'm not understanding the defined() function properly:

class module1::app1 {

  if ! defined(Package['packageA']) {

    package {

      'packageA':

        ;

    }

  }

}

Forgive me if this is an oft asked question.  I couldn't figure out the search term that made sense that would match this scenario.  TIA

Mike.

[Bernd Adamowicz]

You need virtual resources:

 

1.       Define package A in a virtual way:

 

    @package {

        "A" :

            ensure => 'present',

    }

 

2.       Then  realize it wherever needed:

 

class module2::app2 {

 

            realize(Package["A"])

 

            # your stuff here…

}

 

 

Cheers,

Bernd

 

--
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/-/Q5kdE6TkzGYJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[jcbollinger]

On Mar 19, 4:29 am, Bernd Adamowicz <Bernd.Adamow...@esailors.de>
wrote:
> You need virtual resources:

Or else factor out the package to a separate class that all the others
include:

class module0::package_a {
package {
'packageA':
;
}
}

class module1::app1 {
include 'module0::package_a'
# ...
}

class module2::app2 {
include 'module0::package_a'
# ...
}

class module3::app3 {
include 'module0::package_a'
# ...
}


John

[Markus Falb]

On 19.3.2012 14:11, jcbollinger wrote:
>
>
> On Mar 19, 4:29 am, Bernd Adamowicz <Bernd.Adamow...@esailors.de>
> wrote:
>> You need virtual resources:
>
> Or else factor out the package to a separate class that all the others
> include:

But which is better? Is it just a matter of personal preference?
What advantages one gains?
What does need more resources, performance-wise?
--
Kind Regards, Markus Falb

[Luke Bigum]

The use of a class to control Apache is more flexible - it allows you to
encapsulate any common Apache logic into it's own module that your other
classes don't need to worry about.

If you use virtual resources for example and you introduce Debian/Ubuntu
operating systems, you have to go to all your modules that reference
Package[httpd] and introduce logic that installs the Debian equivalent.
On the flip side if you do this in a class, you only have to handle it
in one place.

Using a class for Apache also gives you a place to put common
configuration - maybe in a few months you want every single Apache, no
matter where it is or who runs it, to have mod_status enabled.

--
Luke Bigum

Information Systems
Ph: +44 (0) 20 3192 2520
luke....@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.

[flex]

you can put the package resource in a single class, and include this class in app[1-3],  alternatively, try virtual resources, see:

http://docs.puppetlabs.com/guides/virtual_resources.html

--