Hello.
I''m a about 2 months into a puppet poc. I''ve got the low
hanging
fruit taken care of and have the standard manifests which apply to
every host of a given operating system. Basically just schlepping
lot''s of standard files out to every host of a given OS type. No real
decision making or logic required.
j
Now I''m starting to branch out into node specific configurations
and would appreciate any input if the following is seen as a common
method to applying host specific configurations. As we progress
through our POC I want to have decent/common practices in place as I
teach the rest of the team.
In the following example I created class to support constructing
raidz(2) zpools.
class zfs::zpool {
zpool { "$my_zpool_name":
ensure => ''present'',
raid_parity => "$my_zpool_parity",
raidz => [ "$my_zpool_disks" ]
}
}
Then for any node which will have zpools I include the class and
define the variables like this
node headbone {
# Define my zpool variables
$my_zpool_name = "localdisks"
$my_zpool_parity = "raidz2"
$my_zpool_disks = "c0t2d0 c0t3d0 c0t4d0 c0t5d0
c0t6d0 c0t7d0"
include zfs::zpool
}
Down the road as my needs get more complex and my experience with
puppet grows will I regret this method of node specific
configurations? Anyhoo just looking for any possible gotchas I
haven''t taken into consideration.
TIA. Derek.
--
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.
Anyhoo just looking for any possible gotchas I> haven''t taken into consideration. >Obviously I hadn''t taken into consideration on how I could support multiple zpools on one host. Just figured this out as I went to add a second zpool to the node headbone. So am I wanting to use definitions to support creating multiple zpools (or whatever) per node? I guess this is what Scott was trying to tell me the other day:) Derek.> TIA. Derek.-- 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.
So am I wanting to use> definitions to support creating multiple zpools (or whatever) per > node?Answering my own question after grokking Scott''s email. I ended up with this. # Create raidz or raidz2 zpools define zfs::zpool($ensure = "present", $raid_parity, $raidz) { zpool { "$name": raid_parity => "$raid_parity", raidz => "$raidz" } } node blitzen { zfs::zpool { "donner": raid_parity => "raidz2", raidz => [ "/var/tmp/one /var/tmp/two /var/tmp/ three" ] } This affords me the ability to create mutiple zpools per node. -- 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.
deet wrote:> Obviously I hadn''t taken into consideration on how I could support > multiple zpools on one host. Just figured this out as I went to add a > second zpool to the node headbone. So am I wanting to use > definitions to support creating multiple zpools (or whatever) perIn your case, I think the code in your most recent E-mail is probably close to what you need. So the answer is yes, for what you are trying to do use a define. But you don''t always have to. If each has a different parameter then you have to split them out, but otherwise you can do: resource { [ "foo", "bar" ]: parm1 => "asdf", parm2 => ";lkj" } This is the equivalent of: resource { "foo": parm1 => "asdf", parm2 => ";lkj" } resource { "bar": parm1 => "asdf", parm2 => ";lkj" } You want a definition when you want to use $name or $title in a resource''s parameters. Referring back to what I gave you, the use of $name in the File resources is why a define is necessary. If you didn''t refer to $name ("foo" and "bar") in the resource you could have just done seperate File resources, but it would have broken the DRY principle. << define solaris::media($ensure = "present") { file { "solaris_media_${name}": path => "/opt/SUNWjet/etc/$name", content => template("jumpstart/${name}.erb"), ensure => $ensure, require => File[SUNWjet] # don''t you mean Package[SUNWjet] ? } } ... $media_locs = [ "foo", "bar" ] solaris::media { $media_locs: ensure => present } >> compared to: << file { "solaris_media_foo": path => "/opt/SUNWjet/etc/foo", content => template("jumpstart/foo.erb"), ensure => present, require => File[SUNWjet] } file { "solaris_media_bar": path => "/opt/SUNWjet/etc/bar", content => template("jumpstart/bar.erb"), ensure => present, require => File[SUNWjet] } >> Both should have the same effect, but one is more extensible and requires a lot less typing :) NB, I would define variables in the node and try to avoid creating resources in the node itself (similar to what you initially had). Your manifests will be more dynamic and you can use external nodes: <http://reductivelabs.com/trac/puppet/wiki/ExternalNodes> Also check out extlookup. It''s pretty cool: <http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php> -scott -- 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.