On Friday, March 6, 2015 at 11:36:03 AM UTC-6, Reid Vandewiele wrote: > > 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. > >
It would also be clear and consistent to say that when a manifest is changed, those changes will start being reflected in catalogs emitted by the master within 3 minutes (or 1 or 20). The exact timing is not quite as predictable, but the behavior can still be given as a rule, and without using any variant of the word "cache". > 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. > Both do move away from the default behavior of 3.7, but I don't see how you can support a claim that *either* option would provide *least* astonishment, particularly inasmuch as you also claim that a timeout is more astonishing than either of the other alternatives. I do not find it self-evident, for example, that most users would be more astonished that Puppet eventually notices manifest changes, than that they have to perform some kind of manual action separate from the change itself to make Puppet notice changes. > 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 disagree. Puppet has always required a restart to recognize changes to the Ruby code of server-side custom components, but that still throws people -- sometimes even people who should know better. Not every possible behavior is equally good or predictable, even when you start with a clean slate, even when you can state it as a clear and consistent rule. (And in particular, people seem pre-disposed to expect file changes to be recognized immediately.) > 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. > > I don't think the discussion is (or need be) hung up on implementation terms. I think Adrien had it exactly right that most users will be less surprised by manifest changes taking effect immediately than by them not taking effect until some form of a `notice-my-changes` command is executed. > Is having files live-updated (via guaranteed re-read) a value proposition > itself? > >From a least-astonishment perspective, yes. From some other perspectives, too. > 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. > You are right that those are issues for which reload-required behavior is a win, but not on least-astonishment grounds. Are you stepping back from your position that "least astonishment is absolutely what we should be targeting"? 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/874f8f69-45c6-4034-b7c9-06005dc6f963%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
