On Tuesday, April 22, 2014 7:16:47 PM UTC-5, Andy Parker wrote: > > On Tue, Apr 22, 2014 at 1:32 PM, John Bollinger > <john.bo...@stjude.org<javascript:> > > wrote: > >> >> I could see the REBOOT strategy being used at very sensitive or >> tightly-controlled sites, but I'm inclined to think that ENVDIRCHANGE would >> be preferable to many people on account of the ability it affords to >> trigger cache invalidation without restarting the master. >> >> > Or in more performance oriented sites? It would reduce the number of stat > calls that the master ends up doing. The thinking for this one was that in > a production environment the master only should reread when the manifests > have changed and that should be explicit. This can be done by signaling a > graceful restart of the master for either passenger + apache or nginx + > unicorn. For the apache setup it just takes sending a HUP to apache and for > the nginx setup it takes sending a HUP to unicorn. I think that should > provide a better deployment scenario for masters, but I might be wrong. >
I think that option will be very attractive to some. I do think it wrong, though, to characterize that alternative as "better" in an absolute sense. The relative merits of the different alternatives depend to some extent on site-specific requirements, policy, and characteristics. * ENVDIRCHANGE - watches the directory that represents >>> the environment. Reloads if the directory itself is stale (using >>> filetimeout setting to cap the number of times it checks). [...] >>> >>> >> >> Perhaps it's unneeded, but that's the option I like best among those >> presented. I like having a means to manually flush the cache without >> restarting the master(s). >> >> > Wouldn't a graceful restart work just as well. I like the REBOOT + > graceful restart option because it keeps the behavior of puppet much > simpler and under the control of the user. > Whether a graceful restart would work as well depends on the criteria by which you judge. A restart must involve a service interruption, and that could be significant in some cases (either in the sense of "important" or in the sense of "long"). I'm thinking it might also cause some 'source'd File resources to fail needlessly for catalogs that have recently been served. Moreover, those and any other such issues would be visited on each environment as governed by the combined needs of *all* environments. For example, if the master hosts production and development environments, then every reboot required on account of changes to the dev environment would produce a service interruption for the production environment (too). That runs a bit counter to the whole purpose of environments. On the other hand, flushing the cache of a running instance does not need to involve any service interruption. Furthermore, inasmuch as the user can force a flush by touching a directory -- and in most cases that would in fact be needed to flush without rebooting -- this approach puts the behavior almost as much under direct user control as the REBOOT option does. John -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/8765f26d-20f0-4fb8-8b02-4532f794063c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
