0

Environment

I am currently using Puppet 6.21.1 on Ruby 2.7.4 with PDK 2.3.0 (mostly for linting and launching the Puppet console as a REPL). The OS is macOS Monetery. If it matters, I'm running Ruby under RVM 1.29.12-next with a module-specific gemset.

Objective

I'm trying to test some Hiera lookups within a module on a macOS machine, and am trying to override the kernel, os, and osfamily facts returned on the development box by facter.

[See notes on the X/Y problem at the bottom of the post.]

What I've Tried

I have tried using the FACTERLIB environment variable, various individually-set FACTER_ environment variables, and a custom facts directory with the facter --custom-dir flag. While I have limited success my setting top-level variables with individual FACTER_ prefixed environment variables, I can't seem to get facter to return a defined Hash for facter os that I copied from a Debian or Ubuntu host, which is what I'm currently trying to do for reasons I touch on below.

My current fact override looks like this:

# ${module_repository?}/.myfacts/os.rb

Facter.add(:os) do
  confine :kernal => 'Darwin'
  has_weight = 1_000

  setcode do
    {
      architecture => 'amd64',
      distro => {
        codename => 'focal',
        description => 'Ubuntu 20.04.3 LTS',
        id => 'Ubuntu',
        release => {
          full => '20.04',
          major => '20.04',
        },
      },
      family => 'Debian',
      hardware => 'x86_64',
      name => 'Ubuntu',
      release => {
        full => '20.04',
        major => '20.04',
      },
      selinux => {
        enabled => false,
      },
    }
  end
end

Unfortunately, calling facter --custom-dir=".myfacts" facter os from within the module's top-level directory results in the standard facts (give or take the top-level facter element, which doesn't appear in the output when not running overrides) for macOS Monterey:

facter => 
os => {
  architecture => "x86_64",
  family => "Darwin",
  hardware => "x86_64",
  macosx => {
    build => "21A559",
    product => "macOS",
    version => {
      full => "12.0.1",
      major => "12",
      minor => "0",
      patch => "1"
    }
  },
  name => "Darwin",
  release => {
    full => "21.1.0",
    major => "21",
    minor => "1"
  }
}

Both the X and the Y in my X/Y Problem

How can I get facter to report itself as a Debian-family Ubuntu system so that I can properly test my Hiera v5 lookups under ${module_respository?}/data/os/Debian.yaml from PDK console on my non-Puppetized Darwin development system?

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
  • I'm wondering why ? You can create different facts and use those in your module. You can also generate static facts in `/etc/puppetlabs/facter/facts.d/.yaml`. The convention is that static facts overwrite dynamic facts. – azbarcea Nov 19 '21 at 15:59
  • @azbarcea Because I'm doing *local* testing without a Puppetmaster, and want to test the Hiera data in my local module rather than on the Puppetmaster. That's really kind of the whole point. – Todd A. Jacobs Nov 19 '21 at 17:27
  • To do local testing, I recommend using [specserver](https://serverspec.org/), and if you have a docker environment and what to have end-to-end testing on the real platform, I recommend using (litmus](https://puppet.com/blog/litmus-new-module-acceptance-testing-tool/). On `specserver` you end-up having something like: `let(:osfamilyname) { 'Debian' }`. You can do this for any facts (built-in or custom) – azbarcea Nov 20 '21 at 15:22
  • What kind of tests are you writing? PDK has built-in support for creating and running spec tests of the catalog-building process. These will test for every OS supported by your module, as recorded in the module metadata, in part by presenting an appropriate set of OS-specific facts to the catalog builder. It sounds like you are trying to roll your own version of that, instead of using the facilities that are already available to you. – John Bollinger Nov 21 '21 at 14:57

2 Answers2

0

Try

FACTER_<fact_name>=<fact_value> puppet agent -t ...

See also: https://www.puppetcookbook.com/posts/override-a-facter-fact.html

mThirdy
  • 11
  • 1
0

Using rspec-puppet is the best path forward in my experience. I too haven't had luck injecting facts (in any reliable way) to override... However, rspec-puppet can test with any pre-determined set of facts locally, or from various canned factsets. Give it a shot.