On 15 March 2010 17:26, R.I.Pienaar <r...@devco.net> wrote: > 'lo, > > ----- "Michael DeHaan" <mich...@reductivelabs.com> wrote: > >> Do you have a script/application that shells out to facter or uses it >> from as a Ruby library to collect information? (I'm aware of >> mcollective supporting facter, but that's about it). > > my biggest hassle with it is that it's quite slow. Though I guess that's to > be expected given what it does. > > It would be good if facts can mark themselves volatile or not, and that > Facter.reset (or a similar call) could only affect the facts that have marked > themselves as subject to frequent changes.
Yeah, not sure how this would look in the current api though, I guess something comparable to confine to allow timeouts and also ttl/expiry/cache-control type things on the fact. Again this probably comes after having configuration (so as to set a state dir, default policy, etc). > Looking through my factlist things like architecture hardwareisa, > hardwaremodel - most things that came from dmidecode - kernel version, lsb* > and a fair few more should be fixed and not reset as often. Though it's true > that in newer virtualized environments things like ram size, cpu count etc > can change on the fly. Yeah that's certainly one of the things I want to do, as is if we're calling out to a command to parse it and can cache/process it in one time as opposed to calling a billion ifconfig/dmidecodes that'd be good too. Paul -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
