Feature #4519
Facter should provide a convenient way to cache values
| Status: | Accepted | Start date: | 08/11/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Ken Barber |
% Done: | 0% |
|
| Category: | library | |||
| Target version: | 1.7.0 | |||
| Keywords: | Affected Facter version: | |||
| Branch: | https://github.com/kbarber/facter/tree/ticket/4519-cache | |||
| Votes: | 5 |
Description
I think this have discussed already various times and it is even planned?!. But I couldn’t find a logged ticket and as I stumpled over that problem once again I thought I might want to file a feature request:
Facter should provide a way to:
- cache facts with a certain timeout, so that the fact value gets cache for the defined time
- provide a way to cache any kind of data for a certain amount of time
Why? We might want to have facts that take some time to calculate, however that don’t change much. Or there might be data required to calucate a certain fact which high resource intensive, but doesn’t change often. So what I like to have is similar to the @confine@ a way to set @timeout@, so that if this is set to some seconds/minutes (?) the fact isn’t calculated again until the timeout expired.
For the second point I’d like to have a simple key value store with timeout capability built into facter, so I can cache output of commands, which can then be used amongst different facts.
Example:
xen management tools are getting slower the more VMs you start. Hence @xm list@ can get slower and slower and if you have various facts that are depending on the output of that command and you take the naive approach and call @xm list@ a couple of times, you slowdown facter and hence puppet runs enormously. If I have only one fact using the output it would be nice to let facter cache that fact. However, if I have multiple facts depending on the output of @xm list@ I might want to cache also the output of @xm list@ so that @xm list@ is called really only once per facter run.
Currently you can do that with your own cache implementation hacked into facts, but I think it would be nicer if facter would provide a convenient way to cache things.
Related issues
History
Updated by James Turnbull over 1 year ago
- Category set to library
- Status changed from Unreviewed to Accepted
- Target version set to 1.6.0
Updated by Luke Kanies over 1 year ago
- Subject changed from Facter should provide a convenient way to cache facts to Facter should provide a convenient way to cache values
Updated by Luke Kanies over 1 year ago
I agree this is a good idea, but there definitely needs to be a no-caching mode.
Updated by Nigel Kersten over 1 year ago
Some thoughts from the recent mailing list thread.
- There should be a simple way to mark a fact as cache-once-per-boot
- There should definitely be a no-caching mode and probably —ignorecache just like Puppet
- puppetd —ignorecache should probably cause Facter to ignore the cache
How do we deal with non-privileged users? Each user has a separate cache? They read from the privileged cache location but don’t update it?
Updated by Peter Meier over 1 year ago
- There should be a simple way to mark a fact as cache-once-per-boot
- There should definitely be a no-caching mode and probably —ignorecache just like Puppet
both +1
- puppetd —ignorecache should probably cause Facter to ignore the cache
hmm I’m not sure because @—test@ implies @—ignorecache@ which is used a lot for immediate cli runs. How about a new flag, such as @—ignorefactercache@ ?
How do we deal with non-privileged users? Each user has a separate cache? They read from the privileged cache location but don’t update it?
Good point. Firs I thought that the second solution might be the appropriate one. But then I was thinking about the problem of facts revealing sensitive information. This can currently be restricted with @confine :id => ‘root’@ and if the sensitive information is also only readable by root there is currently no problem with that. But where would we cache such information in the future? The cache would make such information available too all users. So maybe we should go with a per user cache.
Updated by Nigel Kersten over 1 year ago
Do you really run your automated runs with —test? We only ever use —test for manual runs, even though we don’t run puppet as a daemon.
We do puppetd —onetime —no-daemonize in our scheduled runs.
I’m not really convinced we need to add yet another argument to puppetd, but even if we do, I feel that puppetd —test should imply —ignorefactercache.
Updated by Michael Stahnke 8 months ago
- Target version changed from 1.6.0 to 1.6.x
Updated by Ken Barber 5 months ago
- Status changed from Accepted to Duplicate
I’m marking this as a duplicate of #2157 since we added cache during this work. While the original ticket didn’t really ask for this – it was added during this work. It probably wasn’t the appropriate thing to do from a house-keeping perspective … I do apoligise :–).
I’ve created a new specific ticket for cache control #9545 to provide ‘ignorecache’ behaviour gleaned from this ticket. Also ‘cacheonly’ as its related.
Updated by Ken Barber 3 months ago
- Status changed from Duplicate to Re-opened
- Assignee set to Ken Barber
- Target version changed from 1.6.x to 1.7.0
Updated by Ken Barber 3 months ago
- Status changed from Re-opened to Accepted
Updated by Ken Barber 3 months ago
- Branch set to https://github.com/kbarber/facter/tree/ticket/4519-cache
Extracted work from #2157. Tests need to be fixed based on recent work.
Updated by Ken Barber about 1 month ago
Extracted out tmpdir and tmpfile into #10309.