> > Which guy? The OP? Yep, OP, per the rest of the post.
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? Yes, it was actually this necro'd threads main point of emphasis, including subject, introduction, middle and final answer from OP. Even the word "requirement" was used. 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. "Normally" and Puppet dont really go hand in hand with the vast customizable use of it, especially when custom facts come into the equation. Well that's not what Puppet is, or ever was intended to be. Many products start out not intending to be what they become. It may not be the purpose of Puppet, but Puppet uses Facter, which does report facts, so they are basically bonded to each other. If something becomes what it wasn't intended to be, should the designer and creator continue to tell users they are using it wrong? Seems to me a lot of things have failed that way. 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. Querying isn't an issue with mcollective. Nor is puppet going to run with a statelock. I even have a custom fact that says when the facts were gathered, so I have exact time stamps. I'm not so sure that yours is a commonly requested feature. The word "common" means something different to each individual. However, I have had 3 customers request this feature, which have led to searches, which have led to quite a few requests from others, over the years. Just as the OP has requested here. I wouldnt say its common to "hope" puppet recognizes fact values during a run, I would almost say that is expected. I think the best debate I read against our wishes or hopes, was that facts should only be viewed as what they were prior to a catalog run. I guess that makes sense. However, since they CAN and ARE used as a reporting method or "inventory", there should be some form of seeing what they have changed to. The other side of this debate though too, is users that want to see what the facts are BEFORE a puppet run. Current reported facts would only show what they were before the previous run, which is also not an "accurate representation". 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 I suppose most of what I said could use subbing of the word "Puppet" with "Facter". I do agree that Puppet doesn't need to, and probably even shouldn't always grab the changed facts at the end of the run. However, Facter itself is widely used as a reporting or inventory system (and even marketed by puppetlabs as so). Thus, I do agree what you say, in regards to Puppet. However, they are two separate systems that work together. I think most people just want to see Facter expand on the whole gathering of inventory. No need to pull in another inventory management system, when Facter can do it. Facter and Puppet allow you to get new facts at the end, but don't provide any native way of doing so. I think that is the main point people that request this are trying to say. You are in luck, however: Puppet's source is open Yep, and thats what makes it such an amazing tool and great community. As well as allows users like myself, OP, and others, that want this kind of reporting feature, to be able to actually do so. All in all, I truly understand what you're saying, and even agree when it comes to Puppet. Although, I also believe all things can be made better. Giving users the ability to query changed or custom facts, after a puppet run (or heck even without Puppet at all, just via Facter), seems like something that could be made better. Right now, (especially since postrun_command is broke in windows) I run a quick powershell script in its own new session that calls puppet upload facts, or a nohup in the background (if nix), after every puppet run. This keeps it in its own environment and outside of puppets ruby process and env vars. I then use a ENC script to pull in the latest facts and push them to reporting. If I need to see the facts prior to Puppets run, I can also view those, as I store them on the master as well. Best of both worlds; latest correct and latest prior to puppet. Or if need be, we can even go back 2 weeks and see every fact for each time puppet was ran. Thanks for your input and its always good to hear others reasonings and opinions. -- 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/d36b749c-7717-49e2-a057-8faccafb2dc5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
