In multiple places in the Puppet wiki, I see the advice to store the puppermaster configuration in a VCS (specifically, a Subversion repository), and then checkout that Subversion repository into /etc/ puppet. That way, the puppermaster's configuration can be updated by simply running (on the puppetmaster):
$ cd /etc/puppet $ svn update But this approach raises an interesting question: the process of updating a checked-out copy of a Subversion repository is NOT atomic. If the puppetmaster were to read files in /etc/puppet while a lengthy "svn update" operation was updating /etc/puppet to the latest revision (e.g., from revision 6 to revision 7), it is possible that the puppetmaster would see a mix of files from revisions 6 and 7. That could cause problems. 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? If so, what are they? And if not, why not? (Note that you don't have to worry about individual files containing a mix of revision 6 versus revision 7 content, because "svn update" modifies files by first creating a new temporary file, then using the rename(2) system call (which IS atomic) to move the new file into place...) -- 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.
