Need help with defining same package resource in two modules

[Mani Devarajan]

Hello all,
 I have two puppet modules A & B. A module is enabled or disabled with flag set to true or false respectively.
 I need a package pkg1 to do complete the workflow of B.

Module A:
package { "pkg1":
    ensure => "installed"
 }

Module B:
package { "pkg1":
    ensure => "installed"
 }

Case1: A=false, When the B module runs, pkg1 is installed and works fine.

Case2: A=true, when B runs it fails
Error 400 on SERVER:
Duplicate definition: Package[pkg1] is already defined in
file A at line ; cannot redefine at

How do i overcome this issue to complete the workflow of module B in both cases (where A is enabled or disabled)

Thanks,
Mani

[Rahul Khengare]

Hi Mani,

Case2: A=true, when B runs it fails
Error 400 on SERVER:
Duplicate definition: Package[pkg1] is already defined in
file A at line ; cannot redefine at

How do i overcome this issue to complete the workflow of module B in both cases (where A is enabled or disabled)

 

If module A get enable then re-declaration of package[pkg1] resource is happening. Here you can disable the module B.

Thanks and Regards,

Rahul Khengare,

NTT DATA OSS Center, Pune, India.

    

[Martin Alfke]

On Sep 17, 2013, at 8:18 AM, Rahul Khengare <rahul...@gmail.com> wrote:

> Hi Mani,
>
> Case2: A=true, when B runs it fails
> Error 400 on SERVER:
> Duplicate definition: Package[pkg1] is already defined in
> file A at line ; cannot redefine at
>
> How do i overcome this issue to complete the workflow of module B in both cases (where A is enabled or disabled)
>
> If module A get enable then re-declaration of package[pkg1] resource is happening. Here you can disable the module B.
>

Make your package resource virtual and realise the resource in both modules.

[Rahul Khengare]

Refer http://docs.puppetlabs.com/puppet/2.7/reference/lang_virtual.html this for creating and realizing the virtual resource.  

 
Thanks and Regards,

Rahul Khengare

NTT DATA OSS Center, Pune, India.

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/mOHDwWzINdc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[jcbollinger]

And to be clear, the virtual package declaration needs to be factored out of the two classes you presented into a separate one that each class that realizes it will declare.  That class could be in module A or B, or it could as easily be in any other module, but there can still be only one declaration of each resource, whether concrete or virtual.  In that case, however, you could also just put a concrete declaration of pkg1 into that third class, and then including that class would be sufficient -- you wouldn't need to realize any virtual package resource.

Virtual resources make sense in this sort of scheme mainly when their declaring class doesn't know whether the resource will be wanted or not for any given node.  The most canonical example I know is system users: you can have a class that declares virtual User resources for all of the members of a (smallish) organization, which is included on all nodes.  Then on a node-by-node basis, the appropriate users for each node are realized.  If the main purpose of a class is to declare a specific resource, however, then it doesn't usually make sense for the resource to be declared virtually.


John

[Ryan Coleman]

On Mon, Sep 16, 2013 at 10:49 PM, Mani Devarajan <manide...@gmail.com> wrote:

How do i overcome this issue to complete the workflow of module B in both cases (where A is enabled or disabled)

Mani, virtual resources will get the job done but may be heavy-handed for your use case. If you want something a little simpler, check out the ensure_resource function provided by the puppetlabs/stdlib module (search the page for ensure_resource). http://forge.puppetlabs.com/puppetlabs/stdlib

[jcbollinger]

Or don't.  The ensure_resource() function does provide a simple interface, but like any other mechanism that directs catalog compilation by testing the catalog under construction, it introduces an evaluation-order dependency and therefore is fundamentally flawed.

As a threshold issue, the function only really addresses the problem if no resource it protects is ever declared other than via that function or an equivalent mechanism.  That may be relatively easy to control in a small, all-custom manifest set, but it becomes harder to ensure the larger the manifest set becomes, and doubly so as third-party modules are introduced into the mix.

Then, even if a given package is only ever declared via ensure_resource() or an equivalent mechanism, use of ensure_resource() defeats the purpose of Puppet's restriction on multiple declarations by allowing conflicting declarations of the same resource.  If you fail to keep your resource declarations synchronized then you cannot easily predict which declaration will be used, but more importantly, the other ones will NOT be used.  In that case, then, the resource will silently fail to be in the state expected by some of your modules.


John