Puppet users - Apr 2013 - How do I check whether an imported resource has already been defined?

Hello Puppeteers,

please consider the following scenario:  Puppet is supposed to set up similar
(but not necessarily identical) groups of hosts for a range of customers. For
each customer a dedicated filesystem tree needs to be established on host A.

This should not be difficult  using exported File resources, however: How do I
make sure that only the exported File resource of the first created host in a
customer group is imported by host A? Otherwise puppet will -- understandably --
complain about duplicate imported resources on host A:

Error: Another local or imported resource exists with the type and title
File[customer/fs/tree] on node A

In other words: May I use an "if defined()" when collecting resources
on host A -- and if so: How does the syntax to reference a specific _imported_
resource look like? Or would I be able to prevent the creation of an exported
File resource on a customer host when host A already has imported the
appropriate resource from a host previously defined for this customer? (In this
case: How do I reference "File[customer/fs/tree] on node A"?)

There''s no way to tell which host type in a customer group will be
created first (all customers will have at least one host, but not necessarily of
the same type), hence I can''t  pin the exported File resource to a
certain type of host which always has to be installed first.

Or should I consider a completely different approach to solve the problem -- any
suggestion which one?

Thanks a lot for caring

     Patricia



-- 
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+unsubscribe@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, April 24, 2013 7:28:55 AM UTC-5, Patricia Jung
wrote:
>
> Hello Puppeteers, 
>
> please consider the following scenario:  Puppet is supposed to set up 
> similar (but not necessarily identical) groups of hosts for a range of 
> customers. For each customer a dedicated filesystem tree needs to be 
> established on host A. 
>

I''m not sure I follow, but I think you mean "host A" a
designated special
node somewhere.  It''s not clear whether that''s one of the
hosts in a
per-customer group, but maybe that doesn''t matter.
 
>
> This should not be difficult  using exported File resources, however: How 
> do I make sure that only the exported File resource of the first created 
> host in a customer group is imported by host A? Otherwise puppet will -- 
> understandably -- complain about duplicate imported resources on host A: 
>
> Error: Another local or imported resource exists with the type and title 
> File[customer/fs/tree] on node A 
>
> In other words: May I use an "if defined()" when collecting
resources on
> host A -- and if so: How does the syntax to reference a specific _imported_
> resource look like?


No, you can''t, and if you could then you would be better off not to do.
Do
not use defined().  Ever.

You may have a misconception about what exported are or how they work.  
Exported resources provide a means to declare a resource during compilation 
of one node''s catalog that can later be incorporated by reference into
one
or more other nodes'' catalogs.  What does it mean, however, if multiple
nodes export the same resource?

Although there are ways by which particular ones can be selected (see 
below), such a collision usually reflects a design error.  If all the 
exported declarations are the same, then they must not contain any 
node-specific information.  In that case, what was the purpose of exporting 
/ importing?  It would be simpler and better in that case to just declare 
the needed resources directly on the target host.  On the other hand, if 
the declarations differ, and you only want to import one of them, then why 
does it make sense to export all of them?

With that said, you can use a selection predicate when you collect 
resources to filter the resources to collect 
(http://docs.puppetlabs.com/puppet/3/reference/lang_collectors.html).  
Selection predicates can test only the parameters of the exported 
resources, however, not (directly) the node that exported them.  To apply 
this to your case there would need to be some per-host unique parameter 
carried by the exported resources by which you would select.  If nothing 
else presents itself, then perhaps that could be the ''tag''
metaparameter.

 
> Or would I be able to prevent the creation of an exported File resource on 
> a customer host when host A already has imported the appropriate resource 
> from a host previously defined for this customer? (In this case: How do I 
> reference "File[customer/fs/tree] on node A"?) 
>

Not easily, though you could probably create a custom function, or maybe 
even a custom fact, to do this.  But don''t bother: it won''t
reliably
achieve your aim because it''s not safe to assume that node A will be
synced
between the first host in a customer group and all the rest of them.  That 
is, whether node A has *imported* a resource is not a reliable indication 
of whether any node has *exported* that resource.

 
>
> There''s no way to tell which host type in a customer group will be
created
> first (all customers will have at least one host, but not necessarily of 
> the same type), hence I can''t  pin the exported File resource to a
certain
> type of host which always has to be installed first. 
>
> Or should I consider a completely different approach to solve the problem 
> -- any suggestion which one? 
>
>
It sounds to me like exported resources are the wrong solution to this 
problem.  What prevents you from declaring the needed filesystem trees as 
ordinary resources declared for node A?


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+unsubscribe@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Hi John and all,

Am 25.04.2013 um 17:22 schrieb jcbollinger
<John.Bollinger@stJude.org>:
> On Wednesday, April 24, 2013 7:28:55 AM UTC-5, Patricia Jung wrote:
> please consider the following scenario:  Puppet is supposed to set up
similar (but not necessarily identical) groups of hosts for a range of
customers. For each customer a dedicated filesystem tree needs to be established
on host A.
> 
> 
> I''m not sure I follow, but I think you mean "host A" a
designated special node somewhere.  It''s not clear whether
that''s one of the hosts in a per-customer group, but maybe that
doesn''t matter.
A is a designated host outside the per-customer group. To be more specific:
It''s a Nagios host with customer-specific directories for the
customer-specific Nagios objects created both, manually and by the Nagios
exported resources.
> 
> It sounds to me like exported resources are the wrong solution to this
problem.  What prevents you from declaring the needed filesystem trees as
ordinary resources declared for node A?
The customer-specific filesystem tree within the Nagios configuration must not
exist unless there is at least one customer host defined. If I had to declare it
ordinarily for node A I had to touch A''s definitions every time
I''m adding or removing a new customer.

Thanks for caring!

    Patricia

-- 
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+unsubscribe@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, April 26, 2013 5:05:35 AM UTC-5, Patricia Jung
wrote:
>
> Hi John and all, 
>
> Am 25.04.2013 um 17:22 schrieb jcbollinger: 
> > On Wednesday, April 24, 2013 7:28:55 AM UTC-5, Patricia Jung wrote: 
> > please consider the following scenario:  Puppet is supposed to set up 
> similar (but not necessarily identical) groups of hosts for a range of 
> customers. For each customer a dedicated filesystem tree needs to be 
> established on host A. 
> > 
> > 
> > I''m not sure I follow, but I think you mean "host
A" a designated
> special node somewhere.  It''s not clear whether that''s
one of the hosts in
> a per-customer group, but maybe that doesn''t matter. 
> A is a designated host outside the per-customer group. To be more 
> specific: It''s a Nagios host with customer-specific directories
for the
> customer-specific Nagios objects created both, manually and by the Nagios 
> exported resources. 
> > 
> > It sounds to me like exported resources are the wrong solution to this
> problem.  What prevents you from declaring the needed filesystem trees as 
> ordinary resources declared for node A? 
> The customer-specific filesystem tree within the Nagios configuration must 
> not exist unless there is at least one customer host defined. If I had to 
> declare it ordinarily for node A I had to touch A''s definitions
every time
> I''m adding or removing a new customer. 
>
>
You have to touch your manifests and/or data to set up a new customer in 
any case, so I''m not seeing why it should be more of a problem to 
reconfigure node A directly as part of that process, particularly if making 
things work differently would be convoluted or brittle.

Moreover, I think that this could probably be handled in a data-driven 
manner, especially if all the per-customer trees on node A are uniform, or 
at least characterized by a small number of fixed parameters.  That is, you 
likely could arrange things such that you just need to add a bit of 
information to an external file (e.g. an hiera data file) to induce the 
needed declarations for a given group to be made for node A.

Generally speaking, only resources bearing node-specific data are 
appropriate for export.  The canonical example is probably /etc/hosts 
entries (Host resources).  What you have is different: it is 
group-specific, rather than node-specific.  To make it fit into the 
exported resource mold, you would need to somehow designate a special node 
in each customer group that alone exports the resources pertaining to its 
group.  "First to sync" is not a viable designation; instead, you
would
need something tied to node identity.


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+unsubscribe@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Am 26.04.2013 um 15:45 schrieb jcbollinger
<John.Bollinger@stJude.org>:
> Moreover, I think that this could probably be handled in a data-driven
manner, especially if all the per-customer trees on node A are uniform, or at
least characterized by a small number of fixed parameters.  That is, you likely
could arrange things such that you just need to add a bit of information to an
external file (e.g. an hiera data file) to induce the needed declarations for a
given group to be made for node A.
> 
Thanks a lot, I''ll consider this.


Best

  Patricia

-- 
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+unsubscribe@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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.