I have the following setup http://pastebin.com/bWANRpsP And was wondering if anyone could comment on whether my philosophy is correct. The issue I am having is this. 99% of my systems need to be configured identically. However every now and then there is a system that needs a slight tweak. As an example, all systems need to have syslog configured. The syslog class that is included in base simply ensures syslog is installed, running and pushes out a configuration file. That works for 99% of my systems but as there is a system every now and then that needs a slightly different syslog.conf file. How can I build in the logic to the syslog class so that I can specify different configuration files farther down the chain if need be? -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Dec 6, 2010 at 05:23, cyrus <matthewceroni@gmail.com> wrote:> I have the following setup > > http://pastebin.com/bWANRpsP > > And was wondering if anyone could comment on whether my philosophy is > correct. The issue I am having is this. 99% of my systems need to be > configured identically. However every now and then there is a system > that needs a slight tweak. > > As an example, all systems need to have syslog configured. The syslog > class that is included in base simply ensures syslog is installed, > running and pushes out a configuration file. That works for 99% of my > systems but as there is a system every now and then that needs a > slightly different syslog.conf file. How can I build in the logic to > the syslog class so that I can specify different configuration files > farther down the chain if need be?I used a fairly similar model, starting in the 0.25 days, to yours. However, instead of node inheritance (which is quirky) we used a standard define to create that base. So, every system would include that in the node, and it did all the magic to make everything work as you would expect. We used ''define standard'' for that, because at the time a define was the only way you could require parameters to be set in the puppet language; now we would use a paramaterized class, I imagine. We made one of those parameters the "state" of the system, like your "prod" vs "dev" classes, checked them for correctness with a ''case'' statement, and then included the appropriate implementation class based on that. So, something like this: node foo { standard{ $fqdn: status => "prod" } } # now, more like this: node foo { class { "standard": status => "prod" } } define standard ($status) { include $status } Regards, Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 12/05/2010 07:23 PM, cyrus wrote:> I have the following setup > > http://pastebin.com/bWANRpsP > > And was wondering if anyone could comment on whether my philosophy is > correct. The issue I am having is this. 99% of my systems need to be > configured identically. However every now and then there is a system > that needs a slight tweak. > > As an example, all systems need to have syslog configured. The syslog > class that is included in base simply ensures syslog is installed, > running and pushes out a configuration file. That works for 99% of my > systems but as there is a system every now and then that needs a > slightly different syslog.conf file. How can I build in the logic to > the syslog class so that I can specify different configuration files > farther down the chain if need be?This structure doesn''t make much sense. Inherit a class if you need some tweak to the way it behaves, and only then. In your example, you could have class syslog_enable_tcp inherits syslog { # I''m making this up, mkay? ;-) File["/etc/syslog.conf"] { ... } } with the appropriately changed config file. Then your base class include syslog, but on those special machines you mentioned, you include syslog_enable_tcp as well (farther down the chain, as you say). Inherit class base only if any resources defined in it directly (there probably are none) must be different on selected systems. Those systems then include the descendant. Cheers, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.