On Jun 28, 2:36 am, Andreas Kuntzagk <andreas.kuntz...@mdc-berlin.de> wrote:
[... I wrote:] > > In general, facts, including custom facts, are the Puppet means for > > providing nodes' state details to the puppetmaster. > > It's probably the "clean puppet way(tm)" to do it but to write custom facts > you > need to learn some Ruby. Currently I'd like to avoid learning yet another > programming language. There are other ways the GridEngine master can test for > the status of the client. It may indeed be that Puppet is not the best available mechanism for enrolling new execution nodes into GE. Puppet excels at managing (semi-)permanent state details that individually are confined to a single node. It can certainly be applied to more general scenarios, but as you move away from its core focus, Puppet begins to lose some of its appeal. In particular, if you find yourself doing complex things with Execs then you are probably running against the grain. As for custom facts, however, whether you would need to learn any Ruby depends somewhat on the complexity of the fact you need. If the fact value can be represented as the standard output of an OS command then you can just plug it in to the example at http://docs.puppetlabs.com/guides/custom_facts.html#an-example. In that case there is no need to understand the bit of Ruby window dressing that interfaces the command with Facter. Indeed, that window dressing is much more Puppet-specific than Ruby-general anyway. John -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
