I have always been on the fence with this issue. There are certain things you are able to mange with puppet with the use of "ensure => latest" (at least it has always worked for me) Some people say, puppet is meant to maintain a stable build of your system not update it. And some people say, puppet is meant to deploy new configurations and update packages where need be. As you can see it is all what is in the end user's best interest.
There is such a thing as schedules, http://reductivelabs.com/trac/puppet/wiki/TypeReference#id191 Off that page the most useful example would be: schedule { daily: period => daily, range => [2, 4] } exec { "/usr/bin/apt-get update": schedule => daily } However, it seems that it doesn't exactly fit what you are looking for. Maybe use puppet to manage a cron job that stops puppet for the duration of your time-frame? As I see it, upgrading packages can be very dangerous, especially if it is done "automagically". Imagine you are using a redhat based distro, and you have your own yum repo which is managed internally, it has two parts: 1, base pristine copy of the default install packages for whatever your flavor is. 2, internal rpm repo, all of your "custom" built rpms for apache, ruby, php, kernel etc. Some of those "custom" rpms are fairly trivial but all of them can potentially break your entire server/site. It's really hard to say what is the best route for it, I can't answer it myself, I just go with what fits for my team and my situation. Most packages I have are handled by puppet, there are a few packages that I will not ever let puppet manage, Kernel etc.. So, my next question is, would you really want to do a "yum upgrade" on a system? (glibc would suck) It seems like a lengthy process for something that could be done simply by re-kickstarting and running puppet against a new distro version. (from kickstart to ready for code is 7.8minutes, something ridiculous like 5 minutes for a Xen VM) To get around a lot of the issues of upgrading packages, I came up with an interesting solution, use puppet to manage a cron job. The cron job will run on a nightly schedule and pretty much to a "puppet --dry-run --no-background --tags rpm_install" on a config set that is labeled "testing" in SVN, then I ship off the logs and see what would happen if that testing branch were put into production. Of course there is a little more to it, but when you have thousands of servers with about 15 different build types, all you need to do is run one test job on one of each build type. For managing 6 systems, performing a maintenance by hand shouldn't be hard, look into cap shell, or even cssh. Hope that all makes some sense, that is a half-nut-shell of what my standard practice is. -Jason --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
