On Wed, Aug 25, 2010 at 10:09 PM, Luke Kanies <[email protected]> wrote:
> On Aug 25, 2010, at 1:53 PM, Nigel Kersten wrote:
>
>> On Wed, Aug 25, 2010 at 11:17 AM, Luke Kanies <[email protected]> wrote:
>>> Hi all,
>>>
>>> Rein, Paul, and I had a call today discussing whether we should produce a 
>>> 1.6 (I said no, unless there are high priority tickets that really need to 
>>> be worked on), and then what the design goals of 2.0 should be.  I took 
>>> notes on our discussion and atempted to produce a doc capturing it all:
>>>
>>> http://projects.puppetlabs.com/projects/facter/wiki/ArchitectureForTwoDotOh
>>
>> I have a few thoughts churning around about Facter having native
>> support for storing fact evaluation history on the client, which ties
>> into the open feature request for caching fact values, and I noticed
>> you reference a ttl option in #4565.
>>
>
> It'd be great to hear these.

So I feel that it would be immensely useful for Facter to optionally
store a certain amount of historical data about the fact evaluation.

It would be great to be able to simply interrogate info like "when did
the amount of RAM in this machine change?" "what is my kernel version
history?" etc etc.

To get there however, we need a persistent store for facts, which
seems to tie in quite nicely to the idea of having certain facts be
cached, and easily marked as "refresh once per boot" etc.

Facter becomes much more useful as a standalone product with these
capabilities, and ideally we could hook Puppet/Puppet Dashboard into
this to store historical fact data. We could do this at the
Puppet/Dashboard layer, but if we decided to accept the feature
request for caching fact evaluation, then it appears to make more
sense to have Facter support this directly.




>> Simplifying the DSL for the common case is hugely appealing.
>
> Yeah, although I think external, non-ruby facts will end up being more 
> appealing.

Agreed.

-- 
nigel

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

Reply via email to