+1 for foreman ;) generally, external nodes parameters can be complex data structures (e.g. arrays and hashs) but you should know what you are doing ;)
one solution would be to define variables in difference levels, e.g. put your dns settings in the domain/subnet level, put your ipaddress in the host. foreman supports this kind of parameter merge (based on all kind of criteria - see http://theforeman.org/wiki/foreman/External_Nodes#Define-classes-and-variables-per-host cheers, Ohad On Thu, Dec 3, 2009 at 2:01 AM, jw2dot...@gmail.com <jw2dot...@gmail.com>wrote: > There's been off-and-on discussion on this list about external nodes, > and it's provided a lot if insight as to how others are using this > feature. We're trying to move toward it, but struggling with how to > manage all the parameters that we use in our node manifests today. > > All of our modules and manifests are in git with separate puppet > environments (development, testing and production). However, this > also includes all of our node definitions, which is the root of the > problem. What we're trying to avoid is having to commmit changes in > git just to add a new server. Adding a new server should not require > touching the puppetmaster (other than a new cert). > > Below is snippit of a node definition for one of our J2EE application > servers. We use modules for just about everything, but each module > typically has a lot of parameters passed to it... > > node app1.example.com { > > network::interface { "bond0": > address => "192.168.28.71", > gateway => "192.168.28.1", > onboot => "yes", > master => "yes", > slave => ["eth0", "eth1"], > vlan => "no", > netmask => "255.255.255.0", > } > network::interface { "bond0:1": > address => "192.168.28.72", > netmask => "255.255.255.0", > require => Network::Interface["bond0"], > } > network::route { "eth0": > gateway => ["192.168.12.1", "192.168.12.1", "192.168.12.1"], > netmask => ["255.255.255.0", "255.255.255.0", "255.255.255.0"], > address => ["192.168.16.21", "192.168.16.22", > "192.168.16.177"], > } > mount { mymount: > ensure => mounted, > device => 'nfshost:/path/to/something', > fstype => nfs, > name => '/nfs', > dump => "1", > pass => "2", > options => > 'rw,rsize=32768,wsize=32768,hard,tcp,intr,nfsvers=3', > } > tomcat::instance { "my-tomcat-instance": > address => "192.168.28.106", > ensure => "present", > version => "5.", > ssl => false, > dmz => false, > shared => true, > vhosts => > ["localhost","vhost1.example.com","vhost2.example.com"], > cluster => "true", > mport => ["45574", "45575", "45576"], > lport => ["4018","4019","4020"], > } > jboss::instance { "my-jboss-instance": > ensure => present, > ip => "192.168.18.56", > opts => "-server -Xms192M -Xmx1024M - > Dapache.axis.admin.host.allow=\$SERVER_IP, > mclose => "8186", > tomcatver => "50", > jbossver => "3", > lvmname => "myjb", > } > } > > Leaning toward using Cobbler to hold this data, since we use it > anyway. Adding puppet classes to a Cobbler system is easy, but adding > all these parameters just seems like a daunting task. LDAP or Foreman > are possibilities as well. > > Jason > > -- > > 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<puppet-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > > -- 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.
