+1 to this suggestion. -Eric
-- Eric Shamow Sent with Airmail On March 5, 2015 at 6:42:32 PM, Adrien Thebo (adr...@puppetlabs.com) wrote: To me, following the principle of least astonishment indicates that caching be disabled by default; it'll work correctly for new users and has no hidden gotchas. When people want to do performance tuning they're probably fairly sophisticated users and can deal with weird cache invalidation issues; since they're opting into this feature they should be prepared to deal with the ramifications. On Thu, Mar 5, 2015 at 5:19 PM, Owen Rodabaugh <o...@puppetlabs.com> wrote: To clarify, I am asking for opinions on whether the default environment_timeout should be 0 or unlimited in future releases of puppet. The current plan is to default to unlimited. I'm concerned that shipping with this default assumes prior experience and will be another hurdle to getting started with puppet. Anecdotally I've heard that a common question in #puppet is "I changed my puppet code, why isn't it showing when I do a test run?". Conversely setting environment_timeout=0 will result in lower performance, but no need to restart puppet or hit the API to flush a cache to see code changes. The users impacted by this are likely more experienced and would already be managing, or easily able to manage this setting if they had performance concerns or a pre-existing code deployment workflow. Thanks, Owen On Thursday, March 5, 2015 at 3:56:24 PM UTC-8, Trevor Vaughan wrote: Can you use inotify to invalidate the cache via the API call when selected files in your infrastructure change? It looks like you could do this directly from the core https://launchpad.net/inotify-java. You'll just want to queue them up a bit to not go crazy. 10 seconds should probably do it, but you could make that configurable. Trevor On Wed, Mar 4, 2015 at 4:36 PM, Owen Rodabaugh <ow...@puppetlabs.com> wrote: We've been discussing what the default environment_timeout setting should be. There is general agreement that the current 3 minutes is not great. It's both baffling to new users and does not bring in the full performance benefits. Two main perspectives on this: 1. Performance should be the primary driver and that the default of unlimited (cache never automatically refreshes) is preferred. This assumes most users have a code deployment workflow and tooling which can be adjusted to include the steps required to update the cache. These steps are either hitting the puppetserver environment cache endpoint, or restarting the service to cause the cache to update. 2. New user experience should be the primary driver and that a default of 0 (caching off) is preferred. This assumes brand new users will be baffled when they create or modify puppet code on the server and do not see it take effect during their test runs. By the time users encounter performance problems they will be more familiar with puppet, and this setting will be found when they dig into tuning. This setting can be managed per environment, and I'm guessing experienced users will do so. This question is focused on the out of the box defaults. Appreciate your thoughts. Owen -- 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+...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/f524207b-9dff-4e57-a46e-08bd31c640e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvau...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/08a028ba-4d8f-4223-8134-45404cd367ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Adrien Thebo | Puppet Labs -- 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/CALVJ9SJJyVA5utu6vjSvRoOj1J3HiSxezfJmjL4jK4KWm2F7nA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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/etPan.54f92572.327b23c6.cda8%40rassilon. For more options, visit https://groups.google.com/d/optout.
