On 10 March 2010 06:41, Luke Kanies <l...@reductivelabs.com> wrote:
>
> On Mar 9, 2010, at 10:35 PM, Paul Nasrat wrote:
>
>> On 10 March 2010 03:56, Nigel Kersten <nig...@google.com> wrote:
>>>
>>> On Tue, Mar 9, 2010 at 5:52 PM, Luke Kanies <l...@reductivelabs.com>
>>> wrote:
>>>>
>>>> On Mar 9, 2010, at 5:09 AM, Michael DeHaan wrote:
>>>>
>>>>>> {
>>>>>> "facts": {
>>>>>> "network": {
>>>>>> "interface": "eth0",
>>>>>> "ip": "192.168.0.1",
>>>>>> "netmask": "255.255.255.0",
>>>>>> },
>>>>>> "disk": {
>>>>>> "name": "sda1",
>>>>>> "size": "1000",
>>>>>> }
>>>>>> },
>>>>>> }
>>>>>
>>>>>
>>>>> Yep, that's pretty much what I was proposing. I'm a big fan of
>>>>> structured stdin/stdout interfaces for quick extensibiility (and
>>>>> JSON).
>>>>>
>>>>> We could start by doing something that supports non-datastructured
>>>>> facts now, and add datastructures later.
>>>>> For now, it could just assert in the code that the type of each hash
>>>>> key was a string or int.
>>>>
>>>> I concur on the basic plan.
>>>>
>>>> I'd add that having some plain data, like /etc/facter.d/foo, wouldn't be
>>>> all
>>>> bad, either, so you could just statically declare facts.
>>>
>>>
>>> ++
>>>
>>> I reckon something like:
>>>
>>> /etc/facter/facter.conf (main config file)
>>> /var/lib/facter/data.d/ (plain text files containing fact values)
>>> /var/lib/facter/plugins.d/ (foreign language executables returning fact
>>> values)
>>>
>>> The natural location for all these things differs across platforms, so
>>> it should be added to the install.rb script to make them
>>> configurable... http://projects.reductivelabs.com/issues/3361
>>>
>>
>> I'd also love to move the default search path logic not to be
>> $LOAD_PATH.collect { |d| File.join(d, "facter") }, so we can have a
>> sensible (ie not everything under util/) hierachy for facter's core
>> functionality. But that's probably a breaking change, but we can
>> safely add say a configurable location for native facts in parallel
>> with config, key/value fact files and executable fact files.
>
> Can you explain in more detail what you mean here?
>
Currently facter consists of basically
facter.rb
facter/[facts].rb
facter/util/actual_facter_code/helpers
The classes responsible for actually doing things in facter -
resolution, loading, etc are buried under util. It's not a major thing
but I think it's cleaner to split it the other way (make the facts in
a special place, and the code under facter), having
facter/util/config.rb for handling the config seems wrong .
So eg we could eventually try move to having
facter/facts (for ruby facts)
FACTERLIB
I can also see us potentially wanting to think about how we deal with
fact hierachies potentially moving things into directories so that we
can split up or conditionalize/collapse the order of loading a bit. A
lot of facts have implicit dependencies on just one, or two core facts
for the purposes of confines. It
It's not something I'm overly worried about for now, but if we're
changing the code related to ordering I'd like to be provide the
ability to configure the equivalent of FACTERLIB in the config, and
potentially override the behaviour to say *only look here*. That could
work around some of the issues in the past that have bitten us with
testing under Hudson when we change facter and have an earlier facter
installed on the system we pick up stuff from the system and you get
unexpected failures due to the interaction.
Paul
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@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.
