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. -- People are more violently opposed to fur than leather because it is safer to harrass rich women than motorcycle gangs. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
