On Aug 26, 2010, at 12:47 PM, Nigel Kersten wrote: > On Thu, Aug 26, 2010 at 12:43 PM, Luke Kanies <[email protected]> wrote: >> On Aug 26, 2010, at 12:42 PM, Nigel Kersten wrote: >> >>> On Thu, Aug 26, 2010 at 12:08 PM, Rein Henrichs <[email protected]> wrote: >>>> Excerpts from Nigel Kersten's message of Thu Aug 26 11:27:25 -0700 2010: >>>>> 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. >>>> >>>> Yes, this would be very useful. That said, it's not that we need Facter >>>> to store historical data. We need *something* to store historical data. >>>> Probably not Facter. Probably an inventory service. Probably something >>>> that provides a rich query interface, like CouchDB. >>> >>> But if we're considering adding a ttl/caching for facts, aren't we >>> talking about Facter storing historical data anyway? >> >> Adding a ttl isn't actually the same as doing the caching - that is, a given >> fact may want to define its own ttl for downstream users (i.e., Puppet) >> without actually doing any caching. > > So in that case you may get a different value for a fact when running > the Facter binary than when that same fact is used by Puppet? Doesn't > that seem suboptimal?
It might be, but in that case you should set your ttl to zero. If you're comfortable with a long ttl, then it shouldn't matter, right? I guess the question is if there needs to clearly be a direct linkage in facter between that server-side view and the client-side view, and my perspective is, not really. I've always thought of facter as a means of collecting data and as little else as possible. In fact, the first use of Facter was sticking its output in an ldap db, and I wrote a separate tool (enhost) for that, rather than add additional functionality to Facter. >>> Luke's next mail he says: >>> >>> "Would it be acceptable if, say, the puppet agent provided a simple >>> interface to the server-side fact storage, which will already have >>> this? We're working on designing something like this right now, >>> although it's more mental goo than real ideas right now" >>> >>> This would be ok, but how on earth does this work with load-balancing? >>> You have no guarantee that you're hitting the same >>> local-to-the-server fact store when interrogating. >> >> The server-side storage would need to be centralized, which has to be done >> for other reasons anyway. >> >> -- >> I think that's how Chicago got started. A bunch of people in New York >> said, 'Gee, I'm enjoying the crime and the poverty, but it just isn't >> cold enough. Let's go west.' --Richard Jeni >> --------------------------------------------------------------------- >> Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 >> >> >> >> >> -- >> 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. >> >> > > > > -- > 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. > -- The advantage of a classical education is that it enables you to despise the wealth that it prevents you from achieving. -- Russell Green --------------------------------------------------------------------- Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 -- 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.
