On Wed, Apr 23, 2014 at 12:31 PM, John Bollinger <[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. > 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 [email protected]. > 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 [email protected] 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 [email protected]. 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.
