As Eric said there seems to be clear consensus and an issue has been opened to make the change. I think it is still be useful for me to respond in detail to John, but just to wrap up the thoughts - not to further advocate for reload behavior. There seem to be good reasons to choose to serve files live as opposed to read-on-start.
On Fri, Mar 6, 2015 at 11:06 AM, John Bollinger <john.bollin...@stjude.org> wrote: > > > 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". > I'll cede consistent, but I continue to hold that clock-based behavior lacks clarity. The problem is not that the behavior can't be calculated, it's that to a new user experimenting with the product the clock-based behavior hinders their ability to engage in adjust/observe/iterate experimentation. If I'm trying to understand what a product is doing, I want to make a change and observe the result to see if the change I made did what I expected. I want confidence that if I make an adjustment and a change is observed, it is due to my adjustment. This is a feedback loop. The problem with a clock is that after I make my adjustment, there usually won't be any observed change immediately. But, there will be change later. At best, my feedback loop is delayed and it takes me longer to understand what's going on. More realistically, this kind of inconsistent feedback makes me frustrated with the product and don't have confidence that what I'm doing is having the expected effect. After I figure it out, I can work with it. > > > >> 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. > > My assertion that either option provides a least-astonishment experience is indeed built on a belief that clock-based system is Bad (TM), which I first took as a given. I've provided more context for why I believe this to be the case above. Even allowing that this assumption is incorrect, I still believe that option 1 and 2 are much more similar to each other in terms of first-time-user astonishment than either is to clock-based, since both give users consistent feedback. Users expect to have to restart or refresh most services if their configuration file(s) change. I have been considering puppet manifests similar to configuration files in this way. It sounds like most people would more intuitively consider manifests more like *.php files, or something to be *served*. The general opinion in this thread supports that. Given that starting point, I can see how it would be less astonishing to people if changes made to those files were immediately impactful, rather than requiring a reload. > > >> 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"? > > Not at all. I was however coming from the perspective that both options were equivalent on astonishment-grounds, and so was searching for other differentiators. As the consensus is that the two options are not equivalent on astonishment grounds, these other small differences are not important at this level. > > John > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Puppet Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-dev/lnbXyHlviT0/unsubscribe. > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/puppet-dev/874f8f69-45c6-4034-b7c9-06005dc6f963%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > ~Reid -- 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/CAHNFGkOeowhob-atRoHT6FKMugcnhH1HBGor3cxbk5vbt2mHXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
