Issue #2157 has been updated by Yury Zaytsev.
Luke Kanies wrote: > > * Where should the facts go? E.g., /etc/facts.d, /etc/facter.d, /var/, ? Is it possible to make this configurable at the package build time? I would say **/etc/facter.d** makes sense on RHEL if these facts are mostly expected to be one file, written by hand and placed in there by the system administrator (well, ok, it doesn't totally exclude the package manager, i.e. php-* packages own stuff in /etc/php.d, but these are really more like config files, then there are init scripts, /etc/profile.d, network configuration and so on), but other distributions might have their own preferences and adopt their own standard path for facts that they intend to package. I.e. generally plugin-like things would go to **/usr/lib/facter**, but on the other hand, of they are noarch, the standard place would rather be **/usr/share/facter** and so on. It's really hard to please all distributions with one path. ---------------------------------------- Feature #2157: External fact support in /etc/facter.d https://projects.puppetlabs.com/issues/2157 Author: Paul Nasrat Status: In Topic Branch Pending Merge Priority: Normal Assignee: Luke Kanies Category: Target version: 2.0.0 Keywords: Branch: Affected Facter version: 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
