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 <[email protected]> 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 <[email protected]> >> 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 [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/puppet-dev/f524207b-9dff-4e57-a46e-08bd31c640e0%40googlegroups.com >>> <https://groups.google.com/d/msgid/puppet-dev/f524207b-9dff-4e57-a46e-08bd31c640e0%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> [email protected] >> >> -- 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/08a028ba-4d8f-4223-8134-45404cd367ce%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/08a028ba-4d8f-4223-8134-45404cd367ce%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. 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.
