On Mon, Dec 14, 2009 at 2:10 AM, James Turnbull <ja...@lovedthanlost.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Douglas Garstang wrote:
>> On Sun, Dec 13, 2009 at 11:29 PM, Peter Meier <peter.me...@immerda.ch> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>> I'm no expert at external nodes, so I went and read:
>>>> http://reductivelabs.com/trac/puppet/wiki/ExternalNodes
>>>>
>>>> That doc still really doesn't say exactly what external nodes are.
>>>> It's a way of storing node info in an external source such as MySQL or
>>>> LDAP, right?
>>> or a yaml file, a csv file, <whatever you can imagine, can be read by a
>>> script and can be revision controlled>
>>>
>>> cheers pete
>>
>> I don't get it. What's the benefit of putting your nodes in a yaml
>> file or a csv file rather than a puppet node file?
>>
>
> That's just one example. You can back-end it with any script or DB
> containing node information. When the Puppet client connects the
> master queries the external node script and says "Do you have a host
> called insertnamehere?".
>
> This allows you to:
>
> a) saves you defining each node in a Puppet manifest and allowing a
> greater flexibility of maintenance.
> b) potentially query external data sources (such as LDAP or asset
> management stores) that already know about your hosts meaning you
> only maintain said information in one place.
>
> Regards
>
A subtle advantage of using a external nodes tool is that parameters
assigned to nodes in a an external node tool are set a top scope not
in the scope created by the node assignment in language. This leaves
you free to set default parameters for a base node assignment and
define whatever inheritance model you wish for parameters set in the
children. In the end, Puppet accepts a list of parameters for the
node and those parameters when set using an External Node tool are set
at top scope.
That being said, Doug, I don't think external nodes are really the
answer to your problem. Commonly, when modeling client server
applications you need to manage the same file resource. I generally
use class inheritance to model these situations.
I would inside of my syslog_ng module create a base class that models
the client configuration.
class syslog_ng {
....
file {'/etc/syslog-ng/syslog-ng.conf':
...
}
}
Next I would create a child class for modeling the server
configuration. Instead of managing the same file resource twice,
override the relevant parameters for the file resource in your child
class.
class syslog_ng::server inherits syslog_ng {
File['/etc/syslog-ng/syslog-ng.conf'] {
#overide parameters in here.
...
}
}
Now your node assignment that you described will work because you have
eliminated the duplicate resource definition.
http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction#inheritance
Cheers,
Teyo
--
Teyo Tyree :: www.reductivelabs.com :: +1.615.275.5066
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
