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

Reply via email to