When in AIO context, Facter should read the config file from `/etc/puppetlabs/facter/facter.conf`
When not in AIO context, Facter should read facter.conf from the gem root location.
Since `facter.conf` was introduced in Facter 3, the change does not affect clients that migrate from Facter 2 to Facter 4. Client that were using Facter 3, were using the Puppet AIO version, so they will not be impacted affected by this change.
The main advantage of this approach is that we can have different facter.conf files for different gems on Facter (e.g. the Facter from AIO agent can have a facter config, while the one from pe_installer can have another config)
When in AIO context, Facter should read the config file from `/etc/puppetlabs/facter/facter.conf`
When not in AIO context, Facter should read facter.conf from the gem root location.
Since `facter.conf` was introduced in Facter 3, the change does not affect clients that migrate from Facter 2 to Facter 4. Client that were using Facter 3, were using the Puppet AIO version, so they will not be impacted by this change.
The main advantage of this approach is that we can have different facter.conf files for different gems on Facter (e.g. the Facter from AIO agent can have a facter config, while the one from pe_installer can have another config)
When in AIO context, Facter should read the config file from `/etc/puppetlabs/facter/facter.conf`
When not in AIO context, Facter should read facter.conf from the gem root location.
Since `facter.conf` was introduced in Facter 3, the change does not affect clients that migrate from Facter 2 to Facter 4. Client that were are using Facter 3, were are using the Puppet AIO version, so they will not be affected by this change.
The main advantage of this approach is that we can have different facter.conf files for different gems on Facter (e.g. the Facter from AIO agent can have a facter config, while the one from pe_installer can have another config)