On Wed, Apr 23, 2014 at 12:31 PM, John Bollinger <john.bollin...@stjude.org>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. > 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. > > > John > > > > 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/0327a530-82af-4bab-8c90-db844412843b%40googlegroups.com<https://groups.google.com/d/msgid/puppet-dev/0327a530-82af-4bab-8c90-db844412843b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September 22-24 in San Francisco* *Register by May 30th to take advantage of the Early Adopter discount <http://links.puppetlabs.com/puppetconf-early-adopter> **—**save $349!* -- 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/CANhgQXuF6Wff%2BKvMg8q9A1fOuaXGP1F6JX1RX5v3b98T92j5Qw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
