[Puppet Users] Re: Configuring hosts with data from other hosts

jcbollinger
Wed, 15 Aug 2012 13:31:52 -0000

On Tuesday, August 14, 2012 2:27:05 PM UTC-5, Sam wrote:
>
>
> what is the right way to handle this?
>
> On Tuesday, May 12, 2009 7:51:31 AM UTC+1, stever...@gmail.com wrote:
>>
>> So I want to use facts from one host in the configuration of other
>> hosts.
>> Trivial example: setting restrict lines in ntp.conf to allow a
>> monitoring host to query ntpd on remote hosts.
>>
>> So if the monitoring host boots with IP 10.2.2.3 (which may change
>> regularly), and it knows its the monitor host (via some customer
>> facter plugins), I want some global variable to be available
>> ($monitor_host_ipaddress, type of thing) which could be used in
>> tempaltes etc for all other hosts.
>>
>> Exported resources seems close to what I want, but I dont want to
>> export a file, and copy it to other machines. I want to use
>> variables.
>>
>> Or do I have to copy the IP address of the monitor host to each
>> machine, via an exported resource file, and then process it locally in
>> an exec script to build the correct ntp.conf?
>> That doesn''t seem very puppet-ish...
>>
>>
There are basically two kinds of data in Puppet: those managed by Puppet
and those not.  Those that are managed by Puppet are within your control to
distribute and share as you like.  Those that are not managed by Puppet, on
the other hand, are inherently problematic for several reasons, among them
that

   - Puppet cannot verify whether they are correct, nor make them correct
   when they are wrong
   - Puppet cannot tell third-party nodes what the *expected* data values
   are
   - Any record of the actual values you may make on the master is subject
   to going stale without notice

Nevertheless, this sort of request is becoming more common.  If you cannot
or will not convert unmanaged data to managed data, but you must
nevertheless exchange it with other nodes, via the Puppet master, then the
only built-in alternative is exported resources.

The original and main idea of exported resources is for the node that knows
what a resource is actually supposed to look like to declare the node on
behalf of the nodes that need it, which do not necessarily include the one
that declares it.  The canonical example is probably a Host resource.

Exported resources can take you a long way, especially when you consider
that you can export resources of defined and custom types, and that you can
override resources'' properties when you collect them.  For example, you
can
use the Concat module''s defined types to build a custom file consisting
of
some stanzas contributed by the node for which the file is targeted and
others contributed as exported fragments by other nodes.

If you insist upon going meta, or if there seems no other way, then
consider that exported resources don''t have to be collected by any
particular set of nodes, or even by any nodes at all.  Specifically, if
your master is its own client, then you can export resources that will be
collected only by the master, such as data or configuration files, or
fragments of them.  If you do that, then you can use Puppet''s
generate()
function to run suitable local scripts or programs to extract the data you
want from local files managed that way.

If you are using hiera, and you want to *really* make the snake bite its
own tail then you could consider using that approach to manage hiera data
files on the master.  Then your data would be available inside Puppet via
hiera, with no need for (other) external programs or generate().  In Puppet
3, that will allow you even to manage class parameter defaults.

Needless to say, the more meta you get, the more risk there is that your
configuration will swallow itself and explode.


John

--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit