Uploaded image for project: 'PuppetDB'
  1. PuppetDB
  2. PDB-949

Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation.



    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: PE
    • Labels:
    • Environment:

      PE 3.4

    • Template:
    • Story Points:
    • Sprint:
      PuppetDB 2014-10-22


      We are seeing some failures in the PE Puppet Acceptance Tests job where the nodes facts contain a 'trusted' parameter which is reserved and ends up failing when the compiler pulls the facts into scope.

      s60whm7u1kz3zfm.delivery.puppetlabs.net (redhat6-64-1) 09:08:56$  env PATH="/opt/puppet/bin:${PATH}" RUBYLIB="${RUBYLIB}" puppet agent  --test --server s60whm7u1kz3zfm.delivery.puppetlabs.net  
      Info: Retrieving pluginfacts
      Info: Retrieving plugin
      Info: Loading facts
      Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Attempt to assign to a reserved variable name: 'trusted' on node s60whm7u1kz3zfm.delivery.puppetlabs.net
      Warning: Not using cache on failed catalog
      Error: Could not retrieve catalog; skipping run

      This seems to be because puppetdb injects the node.trusted_data into a 'trusted' fact before saving the facts. If these facts are then retrieved from puppetdb and merged into a new node which is then passed to the compiler, the failure occurs. Normally, in PE 3.4, the facts are cached to yaml (because of the settings in /etc/puppetlabs/puppet/routes.yaml) without 'trusted' facts, and Indirection.find_in_cache will find them from there without 'trusted', and everything works.

      So I'm guessing that the runinterval setting, which controls the indirection cache ttl is also involved here.

      I can reliably reproduce this by curling the catalog endpoint of a pe 3.4 master without supplying facts, so long as the yaml cache file is expired or not present for that node.

      [root@ozcd3fnlyrri1rk ~]# curl -H 'Accept: pson' --cert /etc/puppetlabs/puppet/ssl/certs/ozcd3fnlyrri1
      rk.delivery.puppetlabs.net.pem --key /etc/puppetlabs/puppet/ssl/private_keys/ozcd3fnlyrri1rk.delivery.
      puppetlabs.net.pem --cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem https://ozcd3fnlyrri1rk.delivery.p
      [root@ozcd3fnlyrri1rk ~]# rm /var/opt/lib/pe-puppet/yaml/facts/ozcd3fnlyrri1rk.delivery.puppetlabs.net.yaml 
      rm: remove regular file `/var/opt/lib/pe-puppet/yaml/facts/ozcd3fnlyrri1rk.delivery.puppetlabs.net.yaml'? y
      [root@ozcd3fnlyrri1rk ~]# curl -H 'Accept: pson' --cert /etc/puppetlabs/puppet/ssl/certs/ozcd3fnlyrri1rk.delivery.puppetlabs.net.pem --key /etc/puppetlabs/puppet/ssl/private_keys/ozcd3fnlyrri1rk.delivery.puppetlabs.net.pem --cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem https://ozcd3fnlyrri1rk.delivery.puppetlabs.net:8140/production/catalog/ozcd3fnlyrri1rk.delivery.puppetlabs.net
      Attempt to assign to a reserved variable name: 'trusted' on node ozcd3fnlyrri1rk.delivery.puppetlabs.net

      But I have had no luck reproducing the case case failing the PE Puppet Acceptance Tests run. This is the acceptance/tests/agent/agent_disable_lockfile.rb test.


      It's worth noting that you won't see any of this behavior unless Puppet[:trusted_node_data] is true. The default is now true in PE 3.4, but is still false in FOSS.


          Issue Links



              joshua.partlow Joshua Partlow
              QA Contact:
              Kurt Wall
              0 Vote for this issue
              12 Start watching this issue



                  Zendesk Support