On Sun, Jan 18, 2009 at 8:39 PM, Luke Kanies <l...@madstop.com> wrote: > > On Jan 17, 2009, at 7:34 PM, James Turnbull wrote: > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Paul Nasrat wrote: >>> So I was looking through facter thinking about the problem of >>> resolving facts based on namespace eg: ipaddress_eth1 ... >>> >>> I had a quick look at the yaml output as I was thinking about what do >>> facts mean. Initially my eye was drawn to quoting discrepancies. Then >>> I started to think ok so if interfaces is a list, why is it not a >>> list and just rendered to_s in a sane way. Then I thought about >>> things >>> like ipmess.py, the problem we have is the poor mapping to fact by >>> name vs where it's implemented. Looking at ohai, I quite liked the >>> encapsulation where it was present of say interfaces contain named >>> interfaces which have the relevant facts for the specific interface. >>> This got me thinking about the facter data model and loader >>> resolution >>> model. I think we should actually start thinking about the having a >>> first class fact object rather than buried under util and looking for >>> the facts based upon FACTERLIB and the $LOAD_PATH of facter itself. >> >> Agreed. >> >> A tiered data model works a lot better for some (all?) facts. >> Especially if you can traverse up and down the tier for key=value and >> structured output. >> >> I am happy with the first class fact object - Luke? > > I'm a bit unclear on the differences between that and what we have, > but I'm certainly open to a redesign. Facter's design has essentially > not changed since the initial development 4 or so years ago, and given > how small and simple it is, it's pretty unlikely that the original > design is worth retaining. > > I'm certainly all for getting as much insight as we can from ohai.
Something we've been meaning to have a look at is more related to how Puppet works with Facter than standalone facter I guess. A broken fact shouldn't break a Puppet run at all, and it is possible to do this at the moment. -- Nigel Kersten Systems Administrator Tech Lead - MacOps --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---