The principle of least astonishment is absolutely what we should be targeting. The use of any kind of timer upon whose ticks behavior changes is in inarguable opposition to this, whether it's 10 seconds, 3 minutes, or 15 minutes. However, I think the use of implementation terms like "caching" in describing the two proposed options clouds the water a bit, as both options result in clear and consistent behavior.
Described without the term "caching", option 1 effectively proposes that puppet-server should read all configuration files on startup (puppet.conf, auth.conf, fileserver.conf, environments/**/*.pp, etc.), and not automatically re-read any of these files unless the user issues an explicit `service puppet-server reload` command. Described without the term "caching", option 2 effectively proposes that puppet-server should read some configuration files on startup (puppet.conf, auth.conf, fileserver.conf, etc.), and that puppet-server should read directly from disk all relevant files from environments/**/*.pp when compiling a catalog, once per agent request. Both proposals move strongly away from the problem behavior we have today - a clock-based timeout. Were this a new product, either option seems like it would satisfy principle of least astonishment. The only difference between them, from an astonishment perspective, is that long-time Puppet users are accustomed to behavior resembling option 2 (though in the past implementation it's been more optimized, similar to the inotify suggestion put forth by Trevor). I don't know that thinking about it this way changes anyone's opinion, but I do want to make sure we aren't getting hung up on implementation terms in considering what the actual proposed behaviors are. Is having files live-updated (via guaranteed re-read) a value proposition itself? There seem to be some minor benefits to a reload-required behavior. In-progress requests are guaranteed not to get half files from one revision and half files from another if the catalog request timing is particularly bad, since the user won't issue a reload command mid-file-update, and if they do puppet-server will flush in-progress requests anyway. Are those benefits worth considering proposal 2 for? Does this perspective make sense, or am I missing something? ~Reid On Thursday, March 5, 2015 at 6:42:34 PM UTC-8, Adrien Thebo 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 <ow...@puppetlabs.com > <javascript:>> 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 >>>> <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 >>> 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+...@googlegroups.com <javascript:>. >> 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/04bc526f-4c1a-4d6e-b3d1-81589a5868eb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
