In case anyone comes across this same problem, the issue was not with the 
fact the ENC parameters matched facts.  The issue was that I had a flat 
file fact in /etc/facter/facts.d/facts.txt that defined the hostgroup, 
which was populated during provisioning by the Foreman hostgroup value.  I 
also had a Ruby fact distributed by Puppet that defined hostgroup but for a 
subset of my systems using a confine to limit use to just masterless 
systems.  When the ruby fact was nil it the facts.txt would be ignored and 
the nil value used.  Based on debug output this appeared to be behavior in 
Facter and not Puppet.

- Trey

On Wednesday, November 8, 2017 at 3:36:26 PM UTC-5, treydock wrote:
>
> I just upgraded my Puppet masters and PuppetDB to latest Puppet 5 
> releases.  All other systems remain Puppet 3.8.6.  I've discovered that the 
> masters and puppetdb running puppet-agent 5.3.3 are no longer sending ENC 
> (Foreman) parameters as facts to PuppetDB [1].  What's really odd is one of 
> the parameters, hostgroup, is also put in /etc/facter/facts.d/facts.txt as 
> a static external fact.  The value is returned by "facter hostgroup".  This 
> value is no longer being sent to PuppetDB and this is only occurring for 
> agents running 5.3.3, my 3.8.6 agents are still sending their hostgroup 
> value as a fact to PuppetDB.  I also have custom ruby facts like 
> hostgroup_parent that are based on the value of hostgroup and these are 
> returned by facter but no longer exist in PuppetDB for puppet 5.x clients.  
> This hostgroup_parent is also returned by my ENC as a parameter.  It's as 
> if any facts that facter resolves and also exist in ENC as parameters are 
> omitted from uploads to PuppetDB.
>
> I ran puppet with debug on a 5.3.3 client and puppet is picking up the 
> external facts and resolving the values, so something else must be removing 
> the values before being sent to PuppetDB.
>
> Is this behavior intentional?  I don't want to rewrite all my hostgroup 
> based puppet code that queries from puppetdb if this is some kind of bug.
>
> Thanks,
> - Trey
>
> [1]:
>
> puppet-agent 5.3.3:
>
> # curl  --cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem  --cert 
> /etc/puppetlabs/puppet/ssl/certs/$(hostname -f).pem  --key 
> /etc/puppetlabs/puppet/ssl/private_keys/$(hostname -f).pem  --tlsv1  -X GET 
> https://puppetdb.DOMAIN:8081/pdb/query/v4/facts  --data-urlencode 
> 'query=["and",["=", "certname", 
> "puppet0. DOMAIN"],["=","name","hostgroup"]]'
>
> []
>
> puppet 3.8.6:
>
> # curl  --cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem  --cert 
> /etc/puppetlabs/puppet/ssl/certs/$(hostname -f).pem  --key 
> /etc/puppetlabs/puppet/ssl/private_keys/$(hostname -f).pem  --tlsv1  -X GET 
> https://puppetdb. DOMAIN:8081/pdb/query/v4/facts  --data-urlencode 
> 'query=["and",["=", "certname", "logs. DOMAIN"],["=","name","hostgroup"]]'
>
>
> [{"certname":"logs.DOMAIN","name":"hostgroup","value":"base/infrastructure","environment":"production"}]
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/730b556c-4b19-4638-aa3d-607eb9d557f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to