On Mon, Jan 10, 2011 at 11:34 PM, donavan <[email protected]> wrote: > On Jan 3, 1:34 pm, James Ralston <[email protected]> wrote: >> So, here's my question: if you are currently using the "svn update" >> approach to manage /etc/puppet on the puppetmaster, have you taken >> conscious steps to help avoid a race condition? > > A late vote for Ignore It. At puppet camp SF this came up in two > breakout sessions I was in. As I can recall two large sites had seen > resource/manifest version mismatches occur and ignored the race. Noone > in the room had actually had a serious issue because of this. The > resolution for everyone present was to just let the next run correct > the problem.
Another approach is to have a Big Red Button that controls whether or not clients update or not. This can be as simple as an URL that you check before puppet runs, and if the page exists, the clients can update. Then your release process becomes: * Disable all updates * Push changes to production * Wait x minutes to ensure atomic updates * Enable all updates This also has the advantage of giving you a single location that you can use to disable all updates if you've pushed an undesirable change to production that wasn't caught in testing. > > -- > 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. > > -- 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.
