Puppet 5 support - Githubissues

ghoneycutt / puppet-module-facter

Puppet module to manage Facter

Other

2 stars 22 forks source link

Puppet 5 support #57

Closed treydock closed 4 years ago

treydock commented 6 years ago

Similar to what was done on pam module. Figured make this a place to discuss changes for v4.0.0.

treydock commented 6 years ago

@ghoneycutt One thing I'd like to add is optional management of /etc/puppetlabs/facter/facter.conf. I have the need to force facter CLI to load pluginsync facts.d and seemed like managing the facter conf was appropriate for this module.

ghoneycutt commented 6 years ago

Thanks @treydock !! Your help is very much appreciated.

ghoneycutt commented 6 years ago

[x] module hiera data (not doing as there isn't OS specific data until we add windows support)
[ ] use new readme format (https://github.com/ghoneycutt/puppet-module-bind/blob/master/README.md)
[x] use puppet strings
[ ] enable github pages for puppet strings docs
[ ] Have @Phil-Friderici sign off on the spec tests
[x] Add support for facter.conf
[ ] Stop using create_resources()

treydock commented 6 years ago

Any best practice on community modules using lookup() instead of hiera_hash()? Would logic be okay that if $facts_hash_hiera_merge is true, do a deep merge, otherwise just do normal lookup? Seems like deep merge should somehow be optional, I know in my environment I have common.yaml facts hashes and then disable merging in some other levels of hiera. Might be a topic for mailing list?

ghoneycutt commented 6 years ago

it should default to true and definitely use lookup(). @Phil-Friderici made a change recently to the yum module at https://github.com/ghoneycutt/puppet-module-yum/pull/24/commits/5e1de21faf50fa04f39e3108c6c2caf2025f748e

ghoneycutt commented 4 years ago

This is happening in #68 which is prepping for a major version bump!