The biggest issue with adding facts to facter is the latency of waiting for a new release to be bundled into an AIO.

My concrete use case is to feed that fact to the foreman discovery image and then to pull the fact data out via the foreman API to construct host parameters, which are used as inputs to a partition table template.

My concrete use case is to feed that fact to the foreman discovery image and then to pull the fact data out via the foreman API to construct host parameters, which are used as inputs to a partition table template.

I select various nvme devices "by-id" and give them a use which needs to be persistent, even if the pci device ids are re-enumerated (which has happened to me after bios updates).

technically AIO isn't used in the Foreman discovery image but really what's in Foreman packaging when the image is built

so as long as the release is on https://downloads.puppetlabs.com/facter/ we can update it (or did we use the gem from rubygems, can't remember now)

The FDI case is actually the "easy case" in that I can (and have) built a custom image. That PR is more about trying to find a permanent home for the fact code.

Could I please get some review on https://github.com/voxpupuli/puppet-vault_lookup/pull/54

Could I please get some review on https://github.com/voxpupuli/puppet-vault_lookup/pull/54

This message was deleted.

I'm using the elastic_stack 8.0.2 module, the parameter repo defaults to 7, it's then used to build up base_url string, case statement then checks os::family, finds RedHat and puts the base_url into yumrepo, all looks basic. I'm missing something though, as I've set elastic_stack::repo to 8 (confirmed fine with puppet lookup elastic_stack::repo --environment production) retuning 8, yet for some reason base_url is still output with 7

the code looks pretty simple, but somewhere elastic_stack::repo us not being used to build up base_url, I can't find it

sorry, elastic_stack:repo:version is the correct parmeter I was referencing

and there is the problem, sorry, typing it out just made it clear

😄

always happy to help!

odd, how just typing it out to ask for help highlights the problem when you'e typed it in your terminal 20 times trying to debug it

matt, https://en.wikipedia.org/wiki/Rubber_duck_debugging

I like that

all my years, never heard that before

Works for me all the time. Even if I've already been at it for hours

Still working on getting

centos:7.6.1810

acceptance tests working on Fedora 36 using Docker. I've run into three issues I'm having a hard time with: 1. Host key regen needs to be done with ssh-keygen -A or the daemon will refuse to start because of missing host keys (verified manually) 2. systemctl commands fail with: Failed to get D-Bus connection: No such file or directory. Tried various tricks with no luck so far. This also breaks tests relying on systemd after sshd is started manually 3. Systemd doesn't start sshd when the container initializes. Probably related to no. 2. Is this the point where I should give up on CentOS 7 tests? 😝

puppet-zabbix

module and they work fine on GitHub

I'm not really sure what the difference is

I guess your local systemd is way to new and interferes with the container

because those are trusted containers, the dbus is kinda shared

That sounds likely. I think I'll just set up a VM for testing then 🙂

at least for running CentOS 7 tests. 8+ work fine

I like to use

BEAKER_HYPERVISOR=vagrant_libvirt

when I need a real VM

Good idea. That will probably work fine