Re: [Puppet Users] Re: howto trigger action on another client

Andreas Kuntzagk
Mon, 27 Jun 2011 14:37:34 -0000

Thanks for these infos. I think I got at least a vague idea how this works and
can already use it for some simple cases.
One more question:
If I define checks for the "exported exec" (like "creates"
or "onlyif" will
these run on the exporting agent or the executing agent? (my guess is the second
but want to make sure)
If this is the case is there a way to run the "exec" depending on some
checks on
the exporting agent?

regards, Andreas

jcbollinger wrote:
>
> On Jun 24, 9:18 am, Andreas Kuntzagk <andreas.kuntz...@mdc-berlin.de>
> wrote:
>> Daniel Maher wrote:
>>> On 06/24/2011 03:39 PM, Andreas Kuntzagk wrote:
>>>>> Exported resources are the Puppet means for one node to
provide
>>>>> resources for another. In this case, the execution host
could export
>>>>> an Exec resource for the master to collect and apply.
>>>> Hmm, in the (very short) time I''ve been working with
puppet I have not
>>>> stumbled across exported resources. Any pointer where I should
start
>>>> reading?
>>> Exported resources are great fun. :)
>>> http://docs.puppetlabs.com/guides/exported_resources.html
>>>
http://projects.puppetlabs.com/projects/1/wiki/Using_Stored_Configura...
>> According to these exported resources are somewhat similar to virtual
resources.
>> Problem is until now I cannot wrap my brain arount virtual resources so
I don''t
>> understand the exported resources examples.
>
>
> Exported resources are an extended version of virtual resources.  It
> took me a while to catch on to virtual resources, too, but once I got
> it I realized how useful they are.  I''ll attempt to explain:
>
> Normal resource declarations have two key aspects.  First, they
> describe a resource, and second, by their presence in a manifest they
> indicate that that resource should be managed.  For example,
>
> user { "john":
>   ensure => "absent"
> }
>
> describes a User resource whose username is "john", and if it is
> present in a node''s manifest then that tells Puppet that the
matching
> user should be managed on that node -- in this case, User john must be
> ensured absent from the node.
>
> Virtual resources separate those key aspects.  They allow a resource
> to be declared (described) without specifying whether that resource
> should be managed.  For example,
>
> @user { "john":
>   ensure => "absent"
> }
>
> describes a User resource whose username is "john", but by itself
it
> does not direct the Puppet agent to do anything about that user.
> Elsewhere in the manifest, however, that user can be "realized"
to
> indicate to Puppet that yes, User ["john"] should indeed be
managed
> (in this example, poor john would then again be ensured absent).
> Virtual resources that are not realized for a particular node have no
> effect on that node.
>
> There are at least two ways in which this is useful:
>
> 1) If there are resources that must be managed only on some nodes,
> then it can be clean and convenient to declare them virtually, all in
> one place, for all nodes, and then realize just the needed ones on
> each node.  This is a good alternative to bracketing each resource
> with a complicated conditional statement.
>
> 2) Although resources, including virtual ones, can only be *declared*
> once, virtual resources can be *realized* any number of times.  For
> instance, if you had several different classes that wanted to drop
> files in /etc/cron.d/, then they might all want to ensure that that
> directory is present.  They can''t all declare it, else the
> declarations would collide.  One possibility would be to declare it
> virtually, and let all the classes realize it.  (Another would be to
> declare it concretely in a separate class, and have the other classes
> each include that class.)
>
>
> Exported resources are much like virtual ones.  The main difference is
> that exported resources can be collected by any node, not just the
> node that declares them.  For example, suppose you want all your nodes
> to be listed in each other''s /etc/hosts file.  Each node knows its
own
> name and IP address (suppose for simplicity that it has only one), but
> it doesn''t a priori know the others''.  You can do this:
>
> # Export a Host resource describing this node:
> @@host { "$fqdn":
>   ip => "$ipaddress",
>   host_aliases => "$hostname",
>   ensure => "present"
> }
>
> # Collect all nodes'' exported Host resources
> # (including this node''s)
> Host <<| |>>
>
>
> One of the major drawbacks of exported resources is that they require
> persistent storage.  Puppet uses a database for that, which is a bit
> heavy.  That''s one reason why exported resources may not be worth
the
> trouble if this is your only use for them.
>
>
> John