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, [email protected] 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 https://groups.google.com/d/msg/puppet-users/-/EL7f6rreVrEJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
