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.

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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to