On Aug 26, 2010, at 1:21 PM, Nigel Kersten wrote: > On Thu, Aug 26, 2010 at 1:02 PM, Luke Kanies <[email protected]> wrote: >> 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? > > It shouldn't matter, but it creates an situation that can make > debugging difficult, unless the plan is for facter --puppet > invocations to give you an accurate view of what Puppet actually sees.
I concur, but that's the case in nearly all significant infrastructures, right? I think you're right that a high priority needs to be on making debugging simple. I've been planning on adding client-side interfaces to the server's data, which should make this straightforward. >> 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. > > I think this restricts the utility of Facter to a point where it may > as well simply be part of Puppet. I think it's exactly the opposite - because it doesn't include any of the features that Puppet wants, it's more generically useful. But I get what you're saying, and I'm not opposed to an operational mode in Facter that does this. It just doesn't fit enough with how we need to use it that it's worth us spending a lot of time on it. It should be straightforward to add, though, right? -- That was just a drill of the emergency y2k system. Had this been a real emergency, we would've also dumped a bucket of spiders on you and yelled out "civilization is collapsing!" --------------------------------------------------------------------- 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.
