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
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
