On Mon, Oct 11, 2010 at 02:09:54PM -0700, Philip Brown wrote: > > Example: > Lets say that I want all machines to run some sort of job, that > updates a central database with information about the state of each > puppet client. > > Lets also say, that I have 1000 machines, so if all of them decide to > do it at the exact same time, it would be a Bad Thing. > So I ideally would like some kind of puppet mechanism that says, > "run this script... but only if there are less than 10 other machines > doing the same thing at this particular moment)"
It may be simply that your example isn't the best expression of what you want, but I wouldn't do it that way. The first point is that I don't see Puppet as a way of making hosts do things, I see it as a way of making them conform to a desired state. If that's a state where they can pass information back (or have it gathered from them) then fine, but I'd use Puppet to set that up, not be the conduit. A more prosaic reason for not using Puppet as the information transport mechanism is that a puppet run already puts enough of a load spike on the client and master; don't see a good reason to add to that. I also think that such a mechanism would be complex and fragile and have real problems scaling. I would look at using snmp traps to relay that information; it wouldn't be hard to use puppet to create a distributed system which could cope with the load. Do you have an example that would make a more direct case for puppet having the kind of mechanism you're looking for? -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. -- 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.
