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 <[email protected]> wrote: > On Tue, Mar 1, 2016 at 9:09 AM, JS <[email protected]> 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 [email protected]. >> 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 | [email protected] | 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 [email protected]. > 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 [email protected]. 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.
