On Jan 4, 2011, at 9:39 AM, Daniel Pittman wrote: > On Jan 4, 2011 5:22 AM, "Alan Barrett" <[email protected]> wrote: > > On Mon, 03 Jan 2011, James Ralston 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? If so, what are they? > > > And if not, why not? > > > > I made a conscious decision not to worry about this. I don't expect any > > consequences worse than compile errors (when some but not all of a set > > of mutually-dependent files are updated) or the use of an old version of > > a file. > > We made this same call: the window was small and the risk that it broke > anything for more than the time between two puppet runs was so low it wasn't > worth engineering around until everything else on our network was perfect. > > > If it proves to be a problem in practice, then I'll probably > > use a symlink to switch atomically between two working copies. > > That doesn't solve the problem: if the puppet master is half way through a > compilation run and you switch the repo under it, you will still see it use > mixed versions - because loading the catalog is not atomic either, and > neither is file serving. > > You actually do need to shut down the puppet master (or have it natively > support the VCS like it presently does disk) for this to be truely atomic. >
Even this isn't enough. You could be using a file served by File that's never than the catalog if you update after the catalog is compiled, but before the files are served. Again, we just ignore the problem here. -- 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.
