I love this topic, first though: > dsh, clsh, clusterit, func, hope grown scripts etc you name it, I think I > know them all, the question remains, why shouldn't this kind of > functionallity cant be achived with Puppet? i don't know them all but :) i'll have to check out clsh and clusterit ... i think clsh is the one my technical lead (ab)used and needed me to kill things in a hurry ... anyways though.
Also the mainfest was what i meant == the master key :) I'll go a little deeper than before i think: Push vs pull - push requires each host to be accessible to a central service. The connection from each host will likely need to pass through multiple barriers such as network firewalls, on host firewalls, hosts allow (if tcpwrapped). There are also issues of multiple security zones. One might argue that a centralized configuration management host should be isolated and of the highest security. Alas the powers that be have been known to keep this host(s) on unfirewalled networks with unpatched on host firewalls. Push is undesirable because the high cost to deploy, each firewall, each host need to be configured to allow the connection. Which means any migration (software or IP) may entail serious effort just for access rights. Also push means that even though as Ohad pointed out the manifest is the thing that will / can compromise each host, a pull can be scheduled. Most people probably run hourly cycles. Maybe offsetting production and development hosts (do you want a change to appear quicker or slower on a prod host?) or having tiered solutions with a puppet server for prod and another for dev. Regardless, pull does give the illusion of control because each client needs to ask for the change. So if you are diligent your entire range of hosts won't go down the drain in one go. (we interpret cf in cfengine as cluster f**k for a reason). Push on the other hand implies each host gets the same change at the same time. And even if you're tiered you can still do a lot of damage. So i suggest this: given your need to be able affect each host instantaneously, 1) why not have a second instance of puppet (i don't know if you can run two on the same host though) for urgent things only, and query the different instances at different intervals. 2) have a fact that based on time sets the urgency of your modules, so your regular modules only trip every hour, and your urgent ones straight away. So say have the fact check the time, and if it's 30 past the hour it does the regular changes, every minute does urgent and every (seventh) day at midnight does the ultra rare? regardless, tune your updates to happen every minute. The minutely urgent modules should run quickly and all the other ones that evaluate your fact as meaning they don't need to run should be fast, so your urgent change should probably run alone, and after 10 minutes you just change the urgency. I'd probably have a central file that sets the urgency value for each module, so making the change, updating the variable in the central file and a daemon restart later you have 1 minute to pray you didn't screw up what you're meaning to fix :). Heck, you could even have a clever cronjob that runs on the puppetmaster that checks the file for urgency variables, and 3 minutes after having been touched it replaces it with the non-emergency one and restarts puppetmaster if needed... But implementing push ... you're playing with fire mate :) Cheers chakkerz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
