On 2014-23-04 21:31, John Bollinger 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.
This is actually more performant than checking all directories that can
hold environments since there is only a single stat per environment.
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.
If I understood it correctly, there is a graceful restart. Apache does
it very nicely by letting current workers finish their request, while
all dormant workers are replaced with a new generation. If I understand
that correctly, the server is never unavailable. We also looked at
unicorn/nginx which seems to do the same thing.
We decided to not implement any file/directory watching for 3.6 (hard
deadline in a couple of days). If the graceful restart proves a workable
solution we think that may be adequate but we need to people to try that
first. (Will reconsider if that turns out to not work, be really slow,
etc.).
For 3.6. (in the PR now available) we support timeout based cache
eviction that can be controlled per environment. The default is set to
5 seconds which is a compromise for small / out of the box use and
development.
- henrik
--
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/lj96gk%24bgj%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
