Usage of 'undef' for for a hash about puppet-cron

[roman-mueller]

This is strange, it would then fail for all the other checks in init.pp as well.

I tried to reproduce it but I couldn't:

[root@node1 vagrant]# puppet --version
3.7.3
[root@node1 vagrant]# cat /etc/puppet/hiera.yaml
---
:backends:
  - yaml
  - json
:yaml:
  :datadir: /etc/puppet/hieradata
:json:
  :datadir: /etc/puppet/hieradata
:hierarchy:
  - "%{clientcert}"
  - "%{datacenter}"
  - "%{osfamily}"
  - common
[root@node1 vagrant]# cat /etc/puppet/hieradata/common.yaml 

[root@node1 vagrant]# cat init.pp

include cron
[root@node1 vagrant]# puppet apply init.pp --modulepath=modules/ --hiera_config=/etc/puppet/hiera.yaml
Notice: Compiled catalog for node1.fritz.box in environment production in 0.11 seconds
Warning: The package type's allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false.
   (at /usr/share/ruby/vendor_ruby/puppet/type/package.rb:430:in `block (3 levels) in <module:Puppet>')
Notice: Finished catalog run in 0.08 seconds

Do you have a test case to reproduce this?

[triwats]

Sorry, this was not the clearest from me.

I defined a cronjob (cron::job) using hiera and included cron just like above in my manifest. The hiera_hash lookup is when it seems to fail for me, but only for those that are not defined. In this case, the first to error is the next hiera_hash, or in this case cron::multiple.

To fix this, I ended up replacing all of the undef defaults within the init.pp so it now reads as:

  $cron_job = hiera_hash('cron::job', {})
  if $cron_job {
    create_resources('cron::job',$cron_job)
  }

  $cron_job_multiple = hiera_hash('cron::job::multiple', {})
  if $cron_job_multiple {
    create_resources('cron::job::multiple', $cron_job_multiple)
  }

  $cron_job_hourly = hiera_hash('cron::hourly', {})
  if $cron_job_hourly {
    create_resources('cron::hourly', $cron_job_hourly)
  }

  $cron_job_daily = hiera_hash('cron::daily', {})
  if $cron_job_daily {
    create_resources('cron::daily', $cron_job_daily)
  }

  $cron_job_weekly = hiera_hash('cron::weekly', {})
  if $cron_job_weekly {
    create_resources('cron::weekly', $cron_job_weekly)
  }

  $cron_job_monthly = hiera_hash('cron::monthly', {})
  if $cron_job_monthly {
    create_resources('cron::monthly', $cron_job_monthly)
  }

This works as expected, admittedly our setup is a little muddy and has some quirks to it by now, let me know if you would like some more information on it and I'll provide what I can. We're using a node level hiera definition to create this cron. Am I missing something about undef in 3.7.3 vs 4.*? Did they add support for hashes?

[roman-mueller]

Hmm, that works for me:

[root@node1 vagrant]# cat /etc/puppet/hieradata/common.yaml 
---
cron::job:
  'mysqlbackup':
    command: 'mysqldump -u root mydb'
    minute: 0
    hour: 0
    date: '*'
    month: '*'
    weekday: '*'
    user: root
    environment:
      - 'MAILTO=root'
      - 'PATH="/usr/bin:/bin"'
    description: 'Mysql backup'
[root@node1 vagrant]# cat init.pp

include cron
[root@node1 vagrant]# puppet apply init.pp --modulepath=modules/ --hiera_config=/etc/puppet/hiera.yaml
Notice: Compiled catalog for node1.fritz.box in environment production in 0.20 seconds
Warning: The package type's allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false.
   (at /usr/share/ruby/vendor_ruby/puppet/type/package.rb:430:in `block (3 levels) in <module:Puppet>')
Notice: /Stage[main]/Cron/Cron::Job[mysqlbackup]/File[job_mysqlbackup]/ensure: defined content as '{md5}e318a7a5d4c2442b57d3a9ea83ba6112'
Notice: Finished catalog run in 0.09 seconds

Really weird. Does this fail for you?

$foo = hiera_hash('doesnotexist', undef)
if $foo {
    fail()
}

I tried this on a Puppet 3.7.3 agent and it skips the fail() as expected.

[triwats]

Hi again, I changed the cronjob to be the one within Hiera this morning to ensure that there was not some funk happening with a character in the create_resources and that produced the same issue. I then appended the command that you suggested to the end with some output to see what's going on, and it seems indeed to be substituting for some reason.

      if $foo {
         fail('doesnotexist exists')
      } else {
        fail('we are empty aka undef')
      }

Which returns:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: doesnotexist exists on node intra-cs-05.lhr4.traveljigsaw.com Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run

I am now believing that this could be down to the quirks of our setup rather than an issue with the module and therefore could be within our puppet.conf, one of the potential candidates for this is:

stringify_facts = true

Would it be possible for you to show me the puppet.conf on the agent you are using to reproduce this error?

[roman-mueller]

It's a standard configuration in a Vagrant VM, no changes made:

[root@node1 vagrant]# cat /etc/puppet/puppet.conf 
[main]
    # The Puppet log directory.
    # The default value is '$vardir/log'.
    logdir = /var/log/puppet

    # Where Puppet PID files are kept.
    # The default value is '$vardir/run'.
    rundir = /var/run/puppet

    # Where SSL certificates are kept.
    # The default value is '$confdir/ssl'.
    ssldir = $vardir/ssl

[agent]
    # The file in which puppetd stores a list of the classes
    # associated with the retrieved configuratiion.  Can be loaded in
    # the separate ``puppet`` executable using the ``--loadclasses``
    # option.
    # The default value is '$confdir/classes.txt'.
    classfile = $vardir/classes.txt

    # Where puppetd caches the local configuration.  An
    # extension indicating the cache format is added automatically.
    # The default value is '$confdir/localconfig'.
    localconfig = $vardir/localconfig
[root@node1 vagrant]# puppet config print|grep stringif
stringify_facts = true

[triwats]

Thanks for getting that output for me, upon further reading and testing I believe that it is not the stringify_facts as originally though. Is it possible that you can do the same grep but on 'parser' instead? I believe that I have run into another bug on this version of Puppet that has been addressed here:

https://tickets.puppetlabs.com/browse/PUP-3863

If your parser is set to 'future' I am all out of ideas for now... However this can likely be closed because it seems to be a 'feature' of our puppet installation rather than an issue with the module. Thanks for the time and the help, sorry for drawing false conclusions!