at the very least, I'd alter the process you use to copy the new modules dir into something like $puppetconfigdir/modules_MMDDYYSTUFF and then doing 2 mv's: mv modulepathdir modulepathdir.old mv modules_MMDDYYSTUFF modulepathdir and then puppet should be good, you can start the rm -rf on module path.old
that way at least you're minimizing the number of iops that must occur between when you've gotten the old modules out of the way and you've gotten the new modules into place, Normally, when I do deployments I restart the puppet master gracefully, (apache/nginx/whathaveyou) to make sure that files aren't cached, although the only problems I've actually encountered here involve having a vagrantized puppetmaster .having issues with apache+sendfile On Mon, Mar 24, 2014 at 2:19 PM, John Pyeatt <john.pye...@singlewire.com>wrote: > We are periodically seeing the error > > *Could not retrieve catalog from remote server: Error 400 on SERVER: Could > not find class webadminserver* > > > In our puppet agent logs even though the module/webadminserver files are > there. > > But I'm wondering if there is a timing/file refresh issue involved. > > When we push new code out to our puppetmaster we perform the following > steps: > 1) copy the new code to a temporary location on the puppetmaster > 2) rm -rf the modules directory the puppetmaster uses > 3) cp -r from the temporary location into the modules directory > > Sometimes when the puppet agent's next run we will see the error described > above. I'm wondering if the puppetmaster is not refreshing its inode values > between the time of the rm/cp combination and a puppet agent's attempt to > pull down the new code. > > Has anyone ever seen this? Does my hypothesis make sense? Does anyone have > a better way to deploy the code to puppetmaster remotely without an outage? > > -- > John Pyeatt > Singlewire Software, LLC > www.singlewire.com > ------------------ > 608.661.1184 > john.pye...@singlewire.com > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAEisTL%3DNPpgU%3DrbagtmeJAv-JFXzndHULnB6G7p13Qki7BmEAw%40mail.gmail.com<https://groups.google.com/d/msgid/puppet-users/CAEisTL%3DNPpgU%3DrbagtmeJAv-JFXzndHULnB6G7p13Qki7BmEAw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAC1UU3eys8jd0P-6YzeA8O6mFHJS30Ze%3D1sp1nbUDvHTu67Oxg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
