On Sat, Apr 4, 2009 at 1:29 PM, chakkerz <[email protected]> wrote: > > 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. > True, but I would still argue that a fairly large amount of nodes does not have this limitation, or that SSL traffic is secure enough to open (which can become a standard in your FW rules).
> > 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). > Are you telling you don't have other means of push already today (ssh??) and at the end of the day, how many people don't run puppet twice an hour? (really I'm asking!) there is a risk in having a push, but there is a risk in not having it as well. > 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. > interesting idea... I have to give it some more thought... > > 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? > I assume you are trying to address the server load problem, in this case I would guess (without checking too much) that the compile time would be similar to using tags. > > 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 :) > sounds like an ssh loop is still easier ;) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
