During some recent user discussions there was some confusion on some logging coming from a pdk test unit run. See some example output below

root@rocky8-320 test_320 $ pdk test unit
pdk (INFO): Using Ruby 3.2.3
pdk (INFO): Using Puppet 8.6.0
[✔] Preparing to run the unit tests.
/opt/puppetlabs/pdk/private/ruby/3.2.3/bin/ruby -I/opt/puppetlabs/pdk/share/cache/ruby/3.2.0/gems/rspec-core-3.13.0/lib:/opt/puppetlabs/pdk/share/cache/ruby/3.2.0/gems/rspec-support-3.13.1/lib /opt/puppetlabs/pdk/share/cache/ruby/3.2.0/gems/rspec-core-3.13.0/exe/rspec --pattern spec/\{aliases,classes,defines,functions,hosts,integration,plans,tasks,type_aliases,types,unit\}/\*\*/\*_spec.rb --format progress
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"Rocky", :operatingsystemrelease=>"/^8/", :hardwaremodel=>"x86_64"}, using v4.5.0 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"OracleLinux", :operatingsystemrelease=>"/^7/", :hardwaremodel=>"x86_64"}, using v4.2.2 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"RedHat", :operatingsystemrelease=>"/^8/", :hardwaremodel=>"x86_64"}, using v4.5.2 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"Scientific", :operatingsystemrelease=>"/^7/", :hardwaremodel=>"x86_64"}, using v4.2.2 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"Debian", :operatingsystemrelease=>"/^10/", :hardwaremodel=>"x86_64"}, using v4.5.0 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"Ubuntu", :operatingsystemrelease=>"/^18\\.04/", :hardwaremodel=>"x86_64"}, using v4.5.0 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"windows", :operatingsystemrelease=>"\"2019\"", :hardwaremodel=>"x86_64"}, using v4.4.0 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"windows", :operatingsystemrelease=>"\"10\"", :hardwaremodel=>"x86_64"}, using v4.4.0 instead
Run options: exclude {:bolt=>true}
..........

Coverage Report:

Total resources:   1
Touched resources: 0
Resource coverage:  0.00%

Untouched resources:
  Notify[Hello world]


Finished in 0.50081 seconds (files took 12.36 seconds to load)
10 examples, 0 failures

root@rocky8-320 test_320 $

This raised questions

  • Isn't operatingsystemsrelease and operatingsystem legacy facts?
  • Why couldn't it find Facter at 4.5.1?
  • Why are some OS having to use much older facter 4.2.2 and 4.4.0?

So to answer these questions lets understand what PDK is doing when it calls PDK test unit and runs its rspec tests. There are two particularly useful projects from Vox Pupuli https://github.com/voxpupuli/facterdb, providing the fact sets for different OS during testing and https://github.com/voxpupuli/rspec-puppet-facts which provide the magic behind the loop you see in the templated rspec tests:

on_supported_os(test_on).each do |os, os_facts|

This loop essentially reads your metadata.json file of what OS are supported by your module which looks something like this:

"operatingsystem_support": [
    {
      "operatingsystem": "RedHat",
      "operatingsystemrelease": [
        "7",
        "8",
        "9"
      ]
    },
    {
      "operatingsystem": "Windows",
      "operatingsystemrelease": [
        "10",
        "2012",
        "2012 R2",
        "2016",
        "2019",
        "2022"
      ]
    },

So that brings us to the first question aren't operatingsystem and operatingsystemrelease legacy facts? Well yes they were but if you look at the documentation this this just the parameter names for the metadata.json file to specify what OS and what versions you are supporting.

This loop then runs the get_facts function from FacterDB for each OS and each version your module supports. If you take a look at some of the data in FacterDB you will see in the facts folder set of folders of different Facter Versions and then files named by OS and Version such as this for Redhat 9 for Facter 4.11 https://github.com/voxpupuli/facterdb/blob/master/facts/4.11/redhat-9-x86_64.facts

Looking at the output below we see this produces an output of facts which you may notice are missing some facts which are overly specific or have had the node name updated to generic name.

Image description

This allows you to have sample facts for each OS release on different versions of facter.

So why couldn't it find Facter at 4.5.1 (the gem version PDK was using during these tests) and had to use something else? Well if you first notice the folder structure only goes down to 4.5 and if we first look at Rocky 8 which is in the 4.5 folder we see the facterversion in the file is

"facterversion": "4.5.0"

So the person who provided this data ran it in facter 4.5.0 hence this message was just a warning that there is a small missmatch but its purely informational and for that level of minor difference it unlikely to affect testing.

Now looking at Rhel 7 which could only find 4.2.2 well we can see its not in the folder and this is because Rhel 7 exited support at this point and 4.2 was the last valid supported version of facter for it.

So hopefully this has made this process a bit clearer and made you appreciate how useful these projects are too.