Feature #2157

External fact support in /etc/facter.d

Added by Paul Nasrat over 1 year ago. Updated 15 days ago.

Status:Accepted Start:04/13/2009
Priority:Normal Due date:
Assignee:Paul Nasrat % Done:

0%

Category:-
Target version:2.0.0
Keywords: Branch:
Votes: 0

Description

Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value.

It probably makes sense to initially stick to yaml for data formats, since json doesn’t ship with ruby, and to also allow executable facts to return either a plain string or yaml.

Note that we can do this without supporting any kind of overriding, but it’d be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core.

Given we’re adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name.

Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of ruby.

History

Updated by James Turnbull over 1 year ago

  • Status changed from Unreviewed to Accepted

Updated by Udo Waechter over 1 year ago

This is a wonderful idea. I think that it would be cleaner to have:

@/etc/facter/facter.d@

At least debian-like OSes introduce more and more packages that have @/etc/packagename/@ top directories for theis config files. This is a pretty clean approach and avoids isorder in @/etc@. Maybe something like facter.conf is introduced some time in the future, then this would be @/etc/facter/facter.conf@

And second: Custom facts coud output multiple key-value pairs. This would lead to less files in @facter.d@ The problem that would then arise is, that it would make dynamic facts more difficult to handle: @facter @ might be difficult to implement when one would have another language than ruby for facts.

Updated by Michael DeHaan 6 months ago

  • Tracker changed from Bug to Feature

Updated by Luke Kanies 15 days ago

  • Subject changed from Scripted fact support (eg /etc/fact.d to External fact support in /etc/facter.d

Original description from Paul:

As a fact writer I want a mechanism to write facts in my favourite language and for facter to run them automatically so that I can easily write custom facts.

Given I have a configured directory for scripting facts When a executable script that returns a key value pair is executed Then the fact should be available in facter

Also available in: Atom PDF