Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-7878

Change in Puppet type management breaks defined class checks

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Cannot Reproduce
    • Affects Version/s: PUP 5.1.0
    • Fix Version/s: None
    • Labels:
    • Environment:
    • Template:
    • Acceptance Criteria:
      Hide

      Puppet should run cleanly on a very standard design pattern that includes checking if a class is defined as per examples giving in core puppetlabs modules.

      Show
      Puppet should run cleanly on a very standard design pattern that includes checking if a class is defined as per examples giving in core puppetlabs modules.
    • Method Found:
      Needs Assessment
    • QA Risk Assessment:
      Needs Assessment

      Description

      After upgrading the puppet version on a puppet server from 5.0.1 to 5.1.0 puppet runs on all nodes referencing that master now fail with the same type of error. Downgrading the server's puppet version back to 5.0.1 results in no errors again.

      The bug appear to be related to PUP-7670.

      [root@puppet ~]# puppet agent -t
      Info: Using configured environment 'infrastructure'
      Info: Retrieving pluginfacts
      Info: Retrieving plugin
      Info: Loading facts
      Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, uninitialized constant Puppet::Pops::Types::PClassType at /etc/puppetlabs/code/environments/infrastructure/modules/puppetdb/manifests/master/config.pp:4:34 on node puppet.mydomain}}
       
      When looking at the code referenced, it appears that it is choking on a very common template
      {{class puppetdb::master::config (
        $puppetdb_server             = $::fqdn,
        $puppetdb_port               = defined(Class['puppetdb']) ? {
      

      ie - the defined(Class['foo']) is what causes the problem. On playing on other nodes, not the puppet master, I see the same error in various different modules, depending on what the node requires. For example, on a webserver node using Apache the line that trips this up is:

      [root@mezabaan1 ~]# puppet agent -t
      Info: Using configured environment 'application'
      Info: Retrieving pluginfacts
      Info: Retrieving plugin
      Info: Loading facts
      Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, uninitialized constant Puppet::Pops::Types::PClassType at /etc/puppetlabs/code/environments/application/modules/apache/manifests/service.pp:27:8 at /etc/puppetlabs/code/environments/application/modules/webserver/manifests/static.pp:77 on node mezabaan1.mydomain
      

      if ! defined(Class\['apache::params'])
      

      I can replicate the exact same error in my own modules using the same code pattern.

      Info: Loading facts
      Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, uninitialized constant Puppet::Pops::Types::PClassType at /etc/puppetlabs/code/environments/application/modules/ntpd/manifests/config.pp:5:8 on node mezabaan1.mydomain
      

      define ntpd::config (
        Array[String] $local_servers = [],
      ) {
       
      if ! defined( Class['ntpd::master'])
      

      etc etc.

        Attachments

          Activity

          Hide
          henrik.lindberg Henrik Lindberg added a comment -

          Justin Couch Did you restart puppet server after the update? If you did not then you would see things like this.

          Show
          henrik.lindberg Henrik Lindberg added a comment - Justin Couch Did you restart puppet server after the update? If you did not then you would see things like this.
          Hide
          henrik.lindberg Henrik Lindberg added a comment -

          I can not reproduce this.

          Show
          henrik.lindberg Henrik Lindberg added a comment - I can not reproduce this.
          Hide
          WetHippie Justin Couch added a comment -

          I do restart the puppet server after each puppet version update. Still same problem showed up.

          To further check, I rolled a new puppet server instance starting with 5.0.1, checked I could deploy and then updated to 5.1.0. Same result

          There must be something really subtle with the combination of modules that I'm using and the Ruby install on the server. No idea what that must be. Any suggestions on where to look?

          Show
          WetHippie Justin Couch added a comment - I do restart the puppet server after each puppet version update. Still same problem showed up. To further check, I rolled a new puppet server instance starting with 5.0.1, checked I could deploy and then updated to 5.1.0. Same result There must be something really subtle with the combination of modules that I'm using and the Ruby install on the server. No idea what that must be. Any suggestions on where to look?
          Hide
          henrik.lindberg Henrik Lindberg added a comment -

          Ping Thomas Hallgren - any thoughts - a bit of a mystery - it seems that a reference to the new name causes puppet to blow up hence my thought that this was a mixed versions in puppet server problem.

          Show
          henrik.lindberg Henrik Lindberg added a comment - Ping Thomas Hallgren - any thoughts - a bit of a mystery - it seems that a reference to the new name causes puppet to blow up hence my thought that this was a mixed versions in puppet server problem.
          Hide
          thomas.hallgren Thomas Hallgren added a comment -

          Please run the server with trace enabled and provide a stack trace from the server log.

          Show
          thomas.hallgren Thomas Hallgren added a comment - Please run the server with trace enabled and provide a stack trace from the server log.
          Hide
          WetHippie Justin Couch added a comment -

          I think I've figured it out: Somewhere along the line there's been a minor bug fix in PuppetServer 5.0 issued that my system hasn't picked up and I missed in the logs. In this upgrade, there's enough of a tweak that the error disappears.

          [root@puppet ~]# puppetserver --version
          puppetserver version: 5.0.0

          Yet running yum upgrade on puppet server
          [root@puppet ~]# yum check-update
          Loaded plugins: fastestmirror, langpacks
          Loading mirror speeds from cached hostfile

          • base: centos.mirror.serversaustralia.com.au
          • epel: epel.mirror.digitalpacific.com.au
          • extras: mirror.ventraip.net.au
          • updates: centos.mirror.serversaustralia.com.au
            [snip]
            java-1.8.0-openjdk-headless.x86_64 1:1.8.0.141-1.b16.el7_3 updates
            ....
            puppetserver.noarch 5.0.0-1.sles12 pc_repo

          And then this fails because there's a typo in the package name dependencies:

          --> Finished Dependency Resolution
          Error: Package: puppetserver-5.0.0-1.sles12.noarch (pc_repo)
          Requires: java-1_8_0-openjdk-headless

          Note the package, as installed is 1.8.0 but puppet's yum dependence say 1_8_0.

          Forcing the update to skip errors and all the PType errors go away. So, not sure where the problem then lies - probably with the crew that packaged the 5.0.0 server's latest update? I'm installing Server, R10K and agent all directly from Puppet's repo, not from Centos' repo. So for me now, the problem is less of an issue because I've worked around it.

          Show
          WetHippie Justin Couch added a comment - I think I've figured it out: Somewhere along the line there's been a minor bug fix in PuppetServer 5.0 issued that my system hasn't picked up and I missed in the logs. In this upgrade, there's enough of a tweak that the error disappears. [root@puppet ~] # puppetserver --version puppetserver version: 5.0.0 Yet running yum upgrade on puppet server [root@puppet ~] # yum check-update Loaded plugins: fastestmirror, langpacks Loading mirror speeds from cached hostfile base: centos.mirror.serversaustralia.com.au epel: epel.mirror.digitalpacific.com.au extras: mirror.ventraip.net.au updates: centos.mirror.serversaustralia.com.au [snip] java-1.8.0-openjdk-headless.x86_64 1:1.8.0.141-1.b16.el7_3 updates .... puppetserver.noarch 5.0.0-1.sles12 pc_repo And then this fails because there's a typo in the package name dependencies: --> Finished Dependency Resolution Error: Package: puppetserver-5.0.0-1.sles12.noarch (pc_repo) Requires: java-1_8_0-openjdk-headless Note the package, as installed is 1.8.0 but puppet's yum dependence say 1_8_0. Forcing the update to skip errors and all the PType errors go away. So, not sure where the problem then lies - probably with the crew that packaged the 5.0.0 server's latest update? I'm installing Server, R10K and agent all directly from Puppet's repo, not from Centos' repo. So for me now, the problem is less of an issue because I've worked around it.
          Hide
          henrik.lindberg Henrik Lindberg added a comment -

          Geoff Nichols Not sure if there is anything anyone needs to do here - see the post just before this though as we may have a packaging problem that needs to be looked at / understood (if it is a real problem). Please close as "cannot reproduce" if you think that is fine too.

          Show
          henrik.lindberg Henrik Lindberg added a comment - Geoff Nichols Not sure if there is anything anyone needs to do here - see the post just before this though as we may have a packaging problem that needs to be looked at / understood (if it is a real problem). Please close as "cannot reproduce" if you think that is fine too.
          Hide
          zhigaev Alexey Zhigaev added a comment - - edited

          I have the same issue.

          OS
          CentOS Linux release 7.3.1611 (Core)

          Packages
          puppet5-release-5.0.0-1.el7.noarch
          puppet-agent-5.1.0-1.el7.x86_64
          puppetserver-5.0.0-1.el7.noarch
          java-1.8.0-openjdk-headless-1.8.0.141-1.b16.el7_3.x86_64

          sudo puppetserver --version
          puppetserver version: 5.0.0

          After installing zabbix module from puppet forge mod 'puppet-zabbix', '4.1.3' I got the same error when applying catalog

          sudo /opt/puppetlabs/bin/puppet agent -t --environment production --noop
          Info: Using configured environment 'production'
          Info: Retrieving pluginfacts
          Info: Retrieving plugin
          Info: Loading facts
          Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, uninitialized constant Puppet::Pops::Types::PClassType at /etc/puppetlabs/code/environments/production/modules/zabbix/manifests/agent.pp:331:10 on node puppet

          It seems that defined function does not work properly.

          Show
          zhigaev Alexey Zhigaev added a comment - - edited I have the same issue. OS CentOS Linux release 7.3.1611 (Core) Packages puppet5-release-5.0.0-1.el7.noarch puppet-agent-5.1.0-1.el7.x86_64 puppetserver-5.0.0-1.el7.noarch java-1.8.0-openjdk-headless-1.8.0.141-1.b16.el7_3.x86_64 sudo puppetserver --version puppetserver version: 5.0.0 After installing zabbix module from puppet forge mod 'puppet-zabbix', '4.1.3' I got the same error when applying catalog sudo /opt/puppetlabs/bin/puppet agent -t --environment production --noop Info: Using configured environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, uninitialized constant Puppet::Pops::Types::PClassType at /etc/puppetlabs/code/environments/production/modules/zabbix/manifests/agent.pp:331:10 on node puppet It seems that defined function does not work properly.
          Hide
          thomas.hallgren Thomas Hallgren added a comment -

          Alexey Zhigaev, the only way I can see this happening, is if PuppetServer loaded one version of Puppet and the function call, when it loads for the first time, uses another version of Puppet. This will typically happen when the puppet installation is upgraded without restarting the server. I can't think of any other scenario that would provoke errors like this.

          Show
          thomas.hallgren Thomas Hallgren added a comment - Alexey Zhigaev , the only way I can see this happening, is if PuppetServer loaded one version of Puppet and the function call, when it loads for the first time, uses another version of Puppet. This will typically happen when the puppet installation is upgraded without restarting the server. I can't think of any other scenario that would provoke errors like this.
          Hide
          zhigaev Alexey Zhigaev added a comment -

          It works! Thanks.

          Show
          zhigaev Alexey Zhigaev added a comment - It works! Thanks.

            People

            • Assignee:
              Unassigned
              Reporter:
              WetHippie Justin Couch
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Zendesk Support