On Fri, May 21, 2010 at 8:56 AM, Douglas Garstang <doug.garst...@gmail.com>wrote:
> On Fri, May 21, 2010 at 1:15 AM, Ken Barber <k...@bob.sh> wrote: > > Douglas - what you are trying to do isn't supported in say 0.25.x > > without compromising. I think the discussion regarding you using > > external nodes is a waste of time - I'd rather divert the conversation > > instead talk about what you might want in an ideal world. > > Ken, what I am trying to do is pretty simple in concept. We would like > to be able to update our node manifests programatically via scripts. > Parsing and updating the node manifest files is of course doable, but > not ideal. If all the node details were stored in a more standard > format, like yaml for example, and then some process was run to > convert the yaml files to node manifests, this would be great. Sounds > like external nodes doesn't it? > Is something like extlookup what you're really looking for? http://code.google.com/p/extlookup/ You have a bunch of parameters per host that you wish to be able to update programmatically, so you put all of this into an external data file so you can look up the relevant parameters per host? (I haven't followed all the back and forth in this thread sorry, so apologies if this has been covered.) > > We have 10 instances of jboss running on each server (one per > customer), and we pass parameters back to the various modules by > calling definitions, like this: > > elements::customer { > tfel0: > description => "Some Customer", > web_url => "https://somecustomer.com";, > ensure => running, > enable => true, > version_core => "1.17.17-1", > version_addons => "1.4-1", > db_host => $db_host, > db_port => $db_port, > db_name => $db_name, > db_user => "somecustomer_tfel", > db_pass => "password", > db_min_pool_size => "5", > db_max_pool_size => "10"; > } > > So, there are 10 blocks like that for each node. I don't think anyone > would argue that passing these parameters through definitions rather > than having literally hundreds of global variables is the wrong > choice. If we wanted to upgrade the software version for example, our > script would update the version_core variable in place, and then > trigger a puppet run on the node, thereby forcing an upgrade of the > RPM. We're doing this by hand right now. > > So, as far as external nodes is concerned, it seems like we would be > forced to use hundreds of global variables. I'm at a loss as to why > the guys that wrote puppet didn't consider this. > > That, is what I am trying to do. > > Doug > > -- > 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. > > -- nigel -- 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.
