Just thinking out loud here but how about a daemonized process
(facterd?) that allows for fine grained retrieval of facts and solves
your concurrency issues with an internal mechanism?

Should facterd be unavailable, each process should be able to fall
back to a) gathering all facts or b) reading the cache file and
updating those items that have elapsed.

This way you end up with something like (for example):

os_version => '4 months'
uptime => 'no cache'
ps => 'persist'
etc...

The issue with some of these is that, while they won't change often,
when they change you *really* want to know. Like puppet_version and
ruby_version and possibly ipaddress.

A prod to the daemon with a USR1 (or whatever) should force a re-cache
of items selected as such.

Having a daemon process could also allow for asynchronous fact
collection via SNMP/REST/Whatever....

Those are my initial thoughts anyway.

Trevor

On Wed, May 23, 2012 at 6:31 PM, Hailee Kenney <hai...@puppetlabs.com> wrote:
> We are implementing caching in Facter, and are looking for feedback on how
> we've decided to do so. As further described in this ticket, we've deciding
> against an internal cache because it's really hard to get right in
> a concurrent environment.
>
> Our supported interface will be a simple yaml file on disk using only
> key/value pairs with out-of-band updates.
>
> This will allow us to decouple the cache from the implementation of updating
> the cache, which will allow us to potentially transition to a daemonized
> version of Facter which can do piecemeal expiration of individual facts
> rather than replacement of the entire cache. The update method today might
> be cron, but it allows us some flexibility it how we do the updates.
>
> This method has been proven effective in MCollective.
>
> We know we have some slow fact resolutions, this is not meant to bypass
> those, we'll still need to investigate and solve those issues.
>
> --
> Hailee Kenney
> Development Intern
> Puppet Labs, Inc.
> hai...@puppetlabs.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to