Am Dienstag, 1. März 2016 19:52:12 UTC+1 schrieb Eric Sorenson:
>
> I've been thinking about a config file for Facter, which has historically 
> not been run-time configurable.
>
> The two problems in front of me that seem applicable are:
>
> * Sometimes, certain facts are just plain bad to collect and users would 
> like to prevent them from even being resolved (see FACT-718, FACT-449, ).
> * Some facts are not inherently bad but _are_ expensive and/or change 
> infrequently, so preventing them from being resolved every time would be 
> beneficial (FACT-348)
>
> Are there other problems you're running into in this area that you'd like 
> to see addressed with a "facter.conf"? I'd like to gather all the 
> requirements and start up a little Puppet RFC based on them.
>

I do see the benefits of a facter config to disable or override facts.

I do see problems that puppet manifests depend on facter facts and puppet 
configures facter. if the config is not sent with the module facts it 
requires 2 puppet runs to get the correct config. 

About facter config and override things, maybe the opinionated systemd 
could lend some inspiration: systemd has 4 directories where it looks up 
settings:
- /usr/lib/systemd/system/
- /etc/systemd/system
- /etc/systemd/system.d/${unit}.d/*.conf (does not override, but provides 
the possibility to add settings)
- /run/systemd/system


the last one wins.

maybe something similiar could be done with facter? 

- Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/9204a22c-91d4-49d1-9164-2bf22f865686%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to