On Monday, April 21, 2014 4:29:23 PM UTC-5, henrik lindberg wrote: [...]
> We think there is a core set of strategies that a user should be able to > select. These should cover the typical usage scenarios. > > * NONE - no caching, each catalog product starts with a clean slate. > This is the current state of directory based environments, Is that why a user is reporting over on puppet-users that turning on directory environments explodes his catalog compilation times? I don't see any reason to object to this strategy, but I'm inclined to doubt that many sites will find it useful in production. > and it > could also be made to apply to legacy environments. This is good in > a very dynamic environment / development or low "signal/noise" ratio. > > * REBOOT - (the opposite of NONE) - cache everything, never check for > changes. A reboot of the master is required for it to react to > changes. > This is good for a static configuration, and where the organization > always takes down the master for other reasons when there are changes. > This strategy avoids scanning, and is thus a speed improvement for > configurations with a large set of files. > > I could see the REBOOT strategy being used at very sensitive or tightly-controlled sites, but I'm inclined to think that ENVDIRCHANGE would be preferable to many people on account of the ability it affords to trigger cache invalidation without restarting the master. > * TIMEOUT - cache all environments with a 'time to live' (TTL). When a > request is made for an environment where the TTL has expired it > starts that environment with a clean slate. > This is a compromise - it will pick up all changes (even additions), > but it will take one "TTL" before they are picked up (say 5 minutes; > configurable). > > That one makes me very nervous. It seems like an open invitation for manifest version shear. I would not even consider using it, myself; I'd prefer even scanning. > These three schemes are believed to cover the different usage scenarios. > They all have the benefit that they do not require watching any files > (thereby drastically reducing the number of stat calls). > > Strategy that is probably not needed: > > * ENVDIRCHANGE - watches the directory that represents > the environment. Reloads if the directory itself is stale (using > filetimeout setting to cap the number of times it checks). Thus, it > will reaact to changes to the environment root only (which typically > does not happen when changing content in the environment, but is > triggered if the environments configuration file is added or removed). > To pick up any other changes, the user would need to touch the > directory. > > Perhaps it's unneeded, but that's the option I like best among those presented. I like having a means to manually flush the cache without restarting the master(s). > Strategies we think are not needed: > > * SCAN - like today where every file is watched. > * CONFCHANGE - watch/scan all configuration files. > > Feedback ? > I'm all for moving away from the SCAN approach. As for CONFCHANGE, is the idea basically a more clueful variant of ENVDIRCHANGE? I could imagine that being of interest, but if you're looking to streamline initial rollout then I could see deferring it until you can document demand for it. > --- > Here are a couple of questions to start with... > > * What do you think of the proposed strategies? > See above. > * If you like the scanning strategy, what use cases do you see it would > benefit that the proposed strategies does not handle? > Relative to scanning, they all make it a little harder to use an approach where the master automatically pulls manifests from VCS. > * Any other ideas? > Can the catalog compiler be induced to abandon its progress and restart the current catalog when the cache for its environment is flushed? That might make the TIMEOUT strategy more palatable, and it would be appropriate for some other strategies, too. > * Any use cases you feel strongly about? Scenarios we need to consider... > > If I'm actively changing the manifest set on my master, then I know better than the master when I've done, and I favor being able to hold off on flushing the cache until then. Also, I like being able to flush the cache of just one environment at a time, and without bringing down the master to do so. 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/a80a3c7c-99cd-44ed-aef3-36eaf481604e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
