On Monday, February 29, 2016 at 1:24:44 PM UTC-6, JS wrote: > > Im going to second this guy. >
Which guy? The OP? > I believe puppet should ALWAYS collect facts after it is done. > That's not what anyone else in this necro'd thread said back in its previous life, so exactly what and who are you agreeing with? > The amount of changes it can make to a server, during a catalog run, can > be massive. > Yes, they can, but normally they are zilch (nada, bumpkus, zero). Moreover, even when massive changes are applied, they rarely change the values of any of the standard facts. Of course, all bets are off with custom facts. > Without reporting those changes, bad things can occur. > What? Why? How? > It really really limits the potential of having a complete and correct > inventory system. > Well that's not what Puppet is, or ever was intended to be. > > As Paul has done, I too make the last thing to run on all my catalogs, > another upload of puppet facts. Now I know what changes have been made. > Communicating what changes have been made is the purpose of Puppet's reports. I suppose, though, that you mean you know nodes' current state, inasmuch as node state is reflected by the node facts recorded in PuppetDB. As I observed in my previous response to this thread, however, node facts only ever give you a snapshot of node state, and Puppet is by no means the only thing that might change that state. Even if you upload fresh facts at the end of each Puppet run, it would be a potentially dangerous mistake to rely on PuppetDB to hold an accurate representation of node state between Puppet runs. Furthermore, it is difficult to determine at the time you query PuppetDB whether the node in question actually is between runs, as for each node there will be from seconds to minutes out of each catalog run interval in which a catalog run is in progress. > There are many other people out there that have requested this, so we > can't be the only ones. > I'm not so sure that yours is a commonly requested feature. It is far more common to hope that Puppet will recognize changes to fact values *during* a run, so as to affect what it will apply later in that run. I don't see that particular behavior being implemented any time in the foreseeable future. Your request is at least more feasible. > > On a most basic level, I dont see any possible way to argue for the > current method. > > Is that a solicitation? > Current method: > Collect facts -> change system config -> Don't collect those changes > > Our method: > Collect facts -> change system config -> recollect change facts > > That characterization seems calculated to support your position, based, moreover, on the faulty premise that node facts as recorded in PuppetDB can or should be useful out-of-band as indicators of current node state. Collecting and recording extra node facts puts a little additional load on every machine, and a moderate amount of additional load on PuppetDB. This is a scalability consideration. In the standard configuration, a node's current facts describe the basis on which its most recent catalog was built. This could, in principle, contribute to evaluating whether cached node catalogs are stale. Uploading facts after a run makes such a determination unreliable, thereby foreclosing an opportunity to reduce the work of the most stressed part of the Puppet system. For similar reasons, it also makes troubleshooting harder. Puppet is a configuration management system, not an inventory system. To the extent that it can also serve incidentally as a poor man's inventory system, that's great, but not of much import to me. As far as I am concerned, Puppet is better suited to working alongside or even under an inventory system than it is to working *as* an inventory system. You are in luck, however: Puppet's source is open, and PuppetLabs (sometimes) accepts community contributions. You are free to make your proposed changes yourself, and to submit them to PL for consideration. You would want to do so in the context of a feature-request ticket <https://tickets.puppetlabs.com/>. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ef259b74-6a50-40b2-8cf0-a1117911050d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
