Offline facts

[Khoury Brazil]

I'm writing some facts for laptops and they're dependent on the availability of specific services over the network. I'd like to use the previous data for the fact if the data returned doesn't validate. Is there an existing pattern I can use for that? I currently have it written to reuse the data using Facter.value() after validation but wanted to make sure there wasn't something standardized that I missed.

Thanks,

Khoury

[Felix Frank]

On 08/28/2014 11:01 PM, Khoury Brazil wrote:
> I currently have it written to reuse the data using Facter.value() after
> validation but wanted to make sure there wasn't something standardized
> that I missed.

Can you provide an example of that? I don't really see what you did there.

[Khoury Brazil]

Sorry for the delay Felix. Here's a specific example of a situation where the fact might return what I would consider useless information and I would want to revert back to a the value set previously:

On OS X you can have an active user that is at the console and owns /dev/console. If you want to gather that information it's fairly straightforward. But under certain circumstances the owner of the console is root. In that scenario I'd still want the data set on the fact prior to that to persist. My thinking is that I can just validate the data returned (within the plugin itself) and if it doesn't meet my criteria, I can set the fact to itself using Facter.value(console_user).

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5400A4A4.5020406%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 09/03/2014 06:32 PM, Khoury Brazil wrote:
> Sorry for the delay Felix. Here's a specific example of a situation
> where the fact might return what I would consider useless information
> and I would want to revert back to a the value set previously:
>
> On OS X you can have an active user that is at the console and owns
> /dev/console. If you want to gather that information it's fairly
> straightforward. But under certain circumstances the owner of the
> console is root. In that scenario I'd still want the data set on the
> fact prior to that to persist. My thinking is that I can just validate
> the data returned (within the plugin itself) and if it doesn't meet my
> criteria, I can set the fact to itself using Facter.value(console_user).

So have you tried that?

I would assume that all you achieve by calling Facter.value from within
the fact's own setcode block is an endless loop.

I know of no internal cache for fact values that have been evaluated
earlier.

Even if there were such a thing, how would it work if the "root" case is
it during Facter's first execution?

[jcbollinger]

On Wednesday, September 3, 2014 11:32:54 AM UTC-5, Khoury wrote:

Sorry for the delay Felix. Here's a specific example of a situation where the fact might return what I would consider useless information and I would want to revert back to a the value set previously:

On OS X you can have an active user that is at the console and owns /dev/console. If you want to gather that information it's fairly straightforward. But under certain circumstances the owner of the console is root. In that scenario I'd still want the data set on the fact prior to that to persist. My thinking is that I can just validate the data returned (within the plugin itself) and if it doesn't meet my criteria, I can set the fact to itself using Facter.value(console_user).

As long as you intend to perform the validation inside the fact implementation, the fact can keep and use its own cache somewhere on the system.

Alternatively, the master stores the most recent set of facts provided by each node, and it can be accessed via the REST API.  You could conceivably use that as a fact cache.

Overall, however, it is probably a poor idea to compute or rely on node facts that reflect the dynamic state of the system, as opposed to its (semi-) stable configuration.


John

 

[Jason Antman]

The few times I've had to do things like this (like pulling information from a physical inventory database to find the rack a host is in, for monitoring) I've just cached the fact value on disk, usually using some sort of mtime-based TTL. That being said, I've only done this for facts that are "optional", i.e. if the fact isn't present, something won't be set but it won't affect the actual operation of the system.

-Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7eea2790-537d-45c6-8ee5-d6eb6588e895%40googlegroups.com.

[Khoury Brazil]

Admittedly I haven't. I didn't really want to go chasing after something that has an established practice/pattern or is for some reason a bad idea.

I assumed Facter.value would pull from a cache of some sort, but clearly that was just a speculative fantasy on my part. If it computes it each time Facter.value is called that certainly kills that method.

The rough idea I had in my head was to check to see if the value of the fact was currently set. If it evaluates to "root" and isn't already defined, set nothing or some arbitrary value.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/540786E1.4020004%40Alumni.TU-Berlin.de.

[Khoury Brazil]

On Thu, Sep 4, 2014 at 9:26 AM, jcbollinger <John.Bo...@stjude.org> wrote:

As long as you intend to perform the validation inside the fact implementation, the fact can keep and use its own cache somewhere on the system.

Alternatively, the master stores the most recent set of facts provided by each node, and it can be accessed via the REST API.  You could conceivably use that as a fact cache.

It sounds like a local cache is my best bet. It looks like the puppet labs blog covers this:

http://puppetlabs.com/blog/facter-part-3-caching-and-ttl

 

Overall, however, it is probably a poor idea to compute or rely on node facts that reflect the dynamic state of the system, as opposed to its (semi-) stable configuration.

I absolutely agree. Facts like this would only be used for reporting purposes. Depending on transient states like that for actual application of configuration seems fragile at best.

--

Khoury

 

John

[Spencer Krum]

I've also used facter.d for facts that require longer to run than you want to wait for a Puppet run.

For example a big find to check all of / for setuid files, then count them. Run that in a cron then write to facter.d, then grab it with facter.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAAqoMCYwg5BNQnFVL8jk0dy%3DgHE3oEiwOVK1k7BEqQQhtKbyjw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Spencer Krum
(619)-980-7820