Still very new to puppet, so go easy :-) Bit of a braindump I''m
afraid, but I''d really appreciate any "Yep",
"interesting", "No!!!"
comments.
I''ll start with an example - adding NTP support. This primarily
consists of two configs:
a) NTP clients
- this is quite easy, it''s a templated file requiring the names of
the NTP servers
b) NTP servers
- another templated file, requiring the names of the (other) NTP
servers and the network to allow queries from
This could be the same templated file, but in other circumstances
these two files would be _vastly_ different.
Is having an ntp class for the clients and then overriding this with
an ntpserver class for the servers sensible? I believe I''m correct in
saying that even if I have a setup like this then puppet does what I
want, but I''m not convinced that I should expect or trust that
behaviour.
class basenode {
include ntp
...
}
node fred {
include basenode
...
}
node barney {
include basenode
include ntpserver
...
}
I''d probably prefer to just get the ntp class determine which file to
use. Ideally I''d like to be able to just say "these boxes are the
ntp
servers" and then watch all the boxes get the correct config files :-)
Some psuedocode like:
if ($ntp_server in thisbox.aliases) {
use ntp_server template
else
use ntp_client template
fi
This then leads onto where to store "details" for want of a
better term. I see there has been some discussion about this:
(http://mail.madstop.com/pipermail/puppet-users/2007-May/002649.html)
Some of these details are per server (IP address for example - but I
want to say what it _should_ be, not find out what it currently is on the
machine). Some details are per site. Currently I''m just setting
these in basenode class via:
$site = $hostname ? {
...
}
$dns_servers = $site ? {
...
}
I''ll probably look at moving this over to Facter, I''ve got a
prototype
CSV reader so that I can do a mass import of facts:
hostname, mgmt_ip, site
fred, 192.168.0.2, london
barney, 192.168.1.2, cardiff
I''d really like to see a few more setups on the wiki - I''m
really
happy to see some standardisation efforts underway w.r.t. file
layouts, modules etc.
Once I have some confidence that what I''d doing would be a good
example rather than a bad example, I''ll try and write it up.
Adrian
On May 21, 2007, at 11:26 AM, Adrian Bridgett wrote:> Still very new to puppet, so go easy :-) Bit of a braindump I''m > afraid, but I''d really appreciate any "Yep", "interesting", "No!!!" > comments.Sorry for the delayed response; I''ve been out of town and a bit out of touch.> I''ll start with an example - adding NTP support. This primarily > consists of two configs: > > a) NTP clients > - this is quite easy, it''s a templated file requiring the names of > the NTP servers > > b) NTP servers > - another templated file, requiring the names of the (other) NTP > servers and the network to allow queries from > > This could be the same templated file, but in other circumstances > these two files would be _vastly_ different.Ok.> Is having an ntp class for the clients and then overriding this with > an ntpserver class for the servers sensible? I believe I''m correct in > saying that even if I have a setup like this then puppet does what I > want, but I''m not convinced that I should expect or trust that > behaviour. > > class basenode { > include ntp > ... > } > > node fred { > include basenode > ... > } > > node barney { > include basenode > include ntpserver > ... > }This should behave as you expect, and is exactly how it''s supposed to be done. I''d call that class ''base'' or something; it''s not a node, so...> I''d probably prefer to just get the ntp class determine which file to > use. Ideally I''d like to be able to just say "these boxes are the ntp > servers" and then watch all the boxes get the correct config files :-) > Some psuedocode like: > if ($ntp_server in thisbox.aliases) { > use ntp_server template > else > use ntp_client template > fiIn this case, the ''ntpserver'' tag should be set: if tagged(ntpserver) { ... }> This then leads onto where to store "details" for want of a > better term. I see there has been some discussion about this: > (http://mail.madstop.com/pipermail/puppet-users/2007-May/002649.html) > > Some of these details are per server (IP address for example - but I > want to say what it _should_ be, not find out what it currently is > on the > machine). Some details are per site. Currently I''m just setting > these in basenode class via: > > $site = $hostname ? { > ... > } > > $dns_servers = $site ? { > ... > }Yeah, this is probably the best way.> I''ll probably look at moving this over to Facter, I''ve got a prototype > CSV reader so that I can do a mass import of facts: > > hostname, mgmt_ip, site > fred, 192.168.0.2, london > barney, 192.168.1.2, cardiffIt''d probably be best to put them into a server-side database or CSV file, then write a parser function to retrieve the appropriate values.> I''d really like to see a few more setups on the wiki - I''m really > happy to see some standardisation efforts underway w.r.t. file > layouts, modules etc.Yep, it''d be great if others posted their configs. DavidS has posted his; I think it''s linked somewhere.> Once I have some confidence that what I''d doing would be a good > example rather than a bad example, I''ll try and write it up.That''d be great. -- Never try to tell everything you know. It may take too short a time. --Norman Ford --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> In this case, the ''ntpserver'' tag should be set: > > if tagged(ntpserver) { ... } > >just jupping on that one, i was bitten by that because the tagged function is dependant on the sorting of the source code, is it still the case ? i had: class one { stuf... if tagged(two) ... } class two { stuff } and if i remember it was not working as the parser do this following the source file so if the node include the two class the parser has not ssen the ''two'' classes when tagged() resolve. This become very hard to sort out when you have much import and multiple recipes. But perhaps this is not the case anymore ? -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 25, 2007, at 10:15 AM, ADNET Ghislain wrote:> just jupping on that one, i was bitten by that because the tagged > function is dependant on the sorting of the source code, is it > still the case ? > > i had: > > class one { > stuf... > if tagged(two) ... > } > > class two { > stuff > } > > and if i remember it was not working as the parser do this > following the source file so if the node include the two class the > parser has not ssen the ''two'' classes when tagged() resolve. This > become very hard to sort out when you have much import and > multiple recipes. > > But perhaps this is not the case anymore ?It is the case, but the previous example used classes and subclasses, where ordering doesn''t matter (tags will always be set when a class or its subclass is being evaluated). Order still unfortunately matters for otherwise-unrelated classes. -- Good judgment comes from experience, and experience comes from bad judgment. --Barry LePatner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com