On 08/05/2014 23:17, Andy Parker wrote: > On Wed, Apr 23, 2014 at 12:31 PM, John Bollinger > <[email protected] <mailto:[email protected]>> wrote: > > > > On Tuesday, April 22, 2014 8:19:57 PM UTC-5, henrik lindberg wrote: > > The problem with doing the manual cache invalidation is knowing > which > running instance of the master to talk to > > > > Why would you want to talk only to one? I can't think of a single > reason. If you want to force a cache flush then want to do it for > /all/ instances of the master. > > > > , and it would either need an > IPC mechanism, or that all instances watch the same file - and > then we > are back at the complex behavior we want to avoid... > > > > Well that's one of the advantages of ENVDIRCHANGE. All the > instances watch the environment path directories for changes -- > done. That's the directories themselves, not necessarily their > contents. The whole cache goes stale, for each master instance, if > the mtime of one of the environmentpath directories changes. I > don't see how that yields anything nearly as complicated or quirky > as the cache management approach available now. > > If you wanted to provide a bit richer cache management feature set > then the master could also watch the individual environment > directories (again, the directories themselves) within the > environment base directory. That could allow each environment's > cache to be flushed independently. > > > I've opened PUP-2520 to track this request. If anyone wants to take a > stab at this, please feel free. In the description of the issue, I > provided one way (the one described here) to do this, but if anyone who > implements it has other ideas, please explain it and submit that as a > patch instead.
I just sent a github PR to implement the 'manual' setting along with a face to invalidate a given environment cache: https://github.com/puppetlabs/puppet/pull/2638 > A restart of the rack server takes time, during which Puppet would > be unavailable. On a site afflicted with long catalog compilation > times, or one where that master serves up large files, the restart > could consume enough time to be a problem. Also, on a server that > enforces fine-grained mandatory access controls it could be a much > bigger deal to restart Puppet than just to touch a particular file. All people watching this thread, please try the patch and let me know if that works or not for you. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/536F66FA.4090001%40daysofwonder.com. For more options, visit https://groups.google.com/d/optout.
