Personally, I've never come across a case where I needed a post-mortem fact collection. But, I do tend to write custom types when I need to get things into the catalog so that may be my particular way of doing things coming out.
While this could be useful in some cases for reporting, I would very much like to have the (thread related) ability to add one-off values to the fact DB from either the master or the client. Outside of that, a simple method for extending the PuppetDB schema to store items of interest would be most welcome. Trevor On Wed, Mar 2, 2016 at 3:03 PM, Kylo Ginsberg <k...@puppetlabs.com> wrote: > On Tue, Mar 1, 2016 at 9:09 AM, JS <thecptspar...@gmail.com> wrote: > >> 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. >> > > FYI this same suggestion came up recently in > https://tickets.puppetlabs.com/browse/PUP-5934 (and I've linked this > thread there). > > This strikes me as an ecosystem concern: i.e. I'm not convinced offhand > we'd want to address the base use cases here by submitting facts with the > report, because I wouldn't want to lose the current fact-set-to-catalog > linkage in puppetdb. So I think we'd want to consider how this would be > supported in puppetdb if/as we consider something like this. > > Also, in the spirit of linking related conversations: this idea may also > dovetail with a current thread on puppet-dev: > https://groups.google.com/d/msg/puppet-dev/bebmBUyRETg/v0VFTogWCgAJ. > Specifically, one idea there is to specify fact ttl's, which might in turn > impact fact submission times and fact storage schema, etc. > > Kylo > > >> >> >> >> >> -- >> 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 >> <https://groups.google.com/d/msgid/puppet-users/d36b749c-7717-49e2-a057-8faccafb2dc5%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Kylo Ginsberg | k...@puppetlabs.com | irc: kylo | twitter: @kylog > > -- > 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/CALsUZFGiOoH2gjqaCzE-5pzO97%2BqJ3%2BYvz1SFpakySn8icsbKQ%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-users/CALsUZFGiOoH2gjqaCzE-5pzO97%2BqJ3%2BYvz1SFpakySn8icsbKQ%40mail.gmail.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 -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoXOuU-%2Bavgu84G58FPpW7QF-a0KUmeyEdzmnTfFhJx9FQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
