Who should manage /etc/facter{,/facts.d}?

[Wil Cooley]

I'm starting to try to use the puppet-community/rundeck module, but right away I have run into a snag with something that have bothered me in the past: Both the rundeck module and one of my local modules tries to manage /etc/facter and /etc/facter/facts.d.

I don't see anything in the code or JIRA that suggests that even w/Puppet 4 these directories are automatically created, so it's not unreasonable that each of us should want to ensure the directory exists, but it does seem to step outside of the rundeck module's concerns to try to manage the module.

I would be satisfied enough to ignore the problem and move on if the RPM packages at least created these directories, but they do not.

Wil

[Garrett Honeycutt]

Hi Wil,

I have a module for that :) Few tweaks away from having it as Puppet
Approved, though using it in production now at a few large
installations. By default it will manage /etc/facter/facts.d for you.
You can add facts facter::fact.

https://github.com/ghoneycutt/puppet-module-facter/

This way your modules can reference facter::fact instead of managing
facter themselves.

Best regards,
-g


--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[jcbollinger]

This is one of the classic module incompatibility patterns.  The best solutions all involve factoring out management of the conflicting resources to a class that the two modules can both reference.  That class *could* declare the needed resources virtually, and let other classes realize them, but I like the solution Garrett describes better.  Any way around, though, you can't resolve the module incompatibility without modifying at least one of the conflicting modules.


John