On Wed, 2010-03-24 at 00:20 -0700, Luke Kanies wrote: > Hi all, > > In Brice's post about offloading various parts of Puppet[1] to the web > server, he mentions that Puppet doesn't set the appropriate cache > headers. > > Anyone on the list know what we should be setting here? The only > reason they're not being set is that I didn't know which were > appropriate, so help here would be great.
Usually you need to add 3 headers: * Expires (followed by a date in the future if you want to enable caching, this is for HTTP/1.0) * Cache-Control, followed by 'max-age=<durations-in-s>' and various cache-control stuff like 'public', 'private', or 'must-revalidate'. * And at least a 'Vary: Accept' to make sure a cached content in pson won't be served by a cache for a client asking for 'yaml'. All those are defined in the RFC 2616: http://www.ietf.org/rfc/rfc2616.txt I have a PoC implementation (only for catalogs) of those in: http://github.com/masterzen/puppet/tree/features/http-catalog-cache My plan with this branch was to bring two things: * allow http caching of catalogs (this is accomplished with --catalog_ttl) * split the facts in two parts: a static part that could be used as a key cache, and a dynamic part. I must admit I didn't go far with this (James pointed to me the existence of the broken --dynamicfacts). But in fact, I discovered that most of the HTTP cache can be configured to have cache expiration defaults when the headers are not present, so you can use HTTP caching even when the upstream source doesn't include caching directives. > And note that if we do set the expiration, normally it would be the > period of the runs (half an hour), so it wouldn't save a whole lot, > but I guess we could make that configurable. Yes, caching for 30 mins is not really helpful. It means something only if you can change the settings and purge the cache on demand when the manifests or facts changes (unfortunately as said earlier, some facts are changing way too often, like uptime/free memory). > Either way, though, I'd like to have the right header information in > place to enable caching. > > For those interested in the general topic, I'm starting to do a few > changes to enable better use of catalog caches on both client and > server in a new features/0.25.x/decoupled_compiles branch in my repo. Cool, I'll throw an eye. Obviously doing the caching inside Puppet gives many advantages (compared to external cache), for instance it knows facts semantic, and as such can take better decision for caching/purging cache. And it also knows when the manifests change, which is a plug when you want to purge the catalog cache. On the other hand, caching outside of puppet has some advantages: * using something that is tailored to caching (ie proven to work) * outside of Puppet means, less internal complexity * optional And this also adds many disadvantages, the first one being adding more layer to the stack... That's one of the reason I was talking in the article about using nginx internal cache. So, I'm all in favor of an internal cache solution, if we can have one. > I'll send the patches along once I've got something worth actually > looking at. Good. -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-...@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
