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
"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
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
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