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.

    XMLWordPrintable

    Details

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

      PE 3.4

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

      Description

      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
      uppetlabs.net:8140/production/catalog/ozcd3fnlyrri1rk.delivery.puppetlabs.net                         
      {"document_type":"Catalog","data":{"tags":["puppet_enterprise::profile::master::mcollective","puppet_enterprise","profile","master","mcollective","puppet_enterprise::profile::mcollective::peadmin","peadmin","pe_repo"
      ...
      }
      [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.

      http://jenkins-enterprise.delivery.puppetlabs.net/job/PE%20Puppet%20Acceptance%20Tests/42/label=beaker,layout=64mcd-32a-64a,platform=redhat6/testReport/(root)/tests_agent/agent_disable_lockfile_rb/

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              joshua.partlow Joshua Partlow
              QA Contact:
              Kurt Wall
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support