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 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. > >>>> 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. > > -- 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.
