On Tuesday, September 17, 2013 1:59:02 AM UTC-5, Martin Alfke wrote:
>
>
> On Sep 17, 2013, at 8:18 AM, Rahul Khengare <rahul...@gmail.com<javascript:>> 
> 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. 
>
>
>

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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to