Any timeline for when PDK will support RHEL10 properly? My team is a little frustrated and has resorted to using Jig... Support case references: #01666786 & #01659385 github.com/puppetlabs/pdk-templates/issues/676 "If we need to write tests differently, I don't have a problem with that, but there is no documentation I can find on what is expected or best practice."

Hey Will, I'll ping some PDK experts internally and see if there was a change to how tests should be run. I don't personally know of such a change, but I might have missed something when reviewing the release notes.

Apologies for any confusion, as part of the last release the default Rubocop files where altered to a more streamlined implementation. Where previously we had set out each and every Rubocop rule that we wished to implement one by one, we have changed to instead utilising the default Rubocop standard, with alterations made to match specific implementation choices we have made in the past. As part of this several new rules have been brought in that had previously been missed.

As for the RHEL 10 support, it looks like the work on that has been completed but is pending publishing/release for download, so it should be available Soon™️ ! (I know, it's a vague target, but I'm not clear on when the publishing will happen)

@Will Froning the spec tests themselves should be identical. The scaffolding to set up the tests may be a bit different because the Vox Pupuli devkit handles much of that for you in the framework rather than writing out a bunch of files. There's documentation about the differences at docs.openvoxproject.org/ecosystem/latest/devkit/migrating.html

It's disappointing that RHEL10 still isn't supported, considering it was released in May of 2025...

Hey Will, the RHEL 10 should be out, and I'm not certain what the delay is in getting it out there. One of the areas we are looking to improve is getting the ecosystem of tools updated with matching OS support and the agents, but it would be good to know for your specific case how that shows up. What drives your need to change the OS you are using for PDK? Is it primarily that you are installing modules on agents on a new OS? Are you switching the OS you are doing your development on? I want to be able to advocate for this internally as we work through our newer process for platform additions.

I'll ask the team about the specifics, but my understanding is that when we are developing modules, the PDK test for RHEL10 fails. It's not that we are running PDK from a RHEL10 client, but rather confirming that the modules we produce will work on our RHEL10 clients. I think the trigger for all of this was the SSSD module failing on a RHEL10 client because of the file permissions for sssd.conf differs between RHEL8/9 and RHEL10. That led down the rabbit hole of PDK issues.

Okay, so that would mean that the driving force for your PDK needs is really the agent support of an OS. We should be trying to get the PDK support of an OS out closer to when we do agent support so that you can do module work on those agents.

Yes, if you add RHEL 10 to

metadata.json

as a supported OS, then run

pdk test unit

it doesn't run anything for RHEL 10:

No facts were found in the FacterDB for: [{"os.name" => "RedHat", "os.release.full" => "/^10/", "os.hardware" => "x86_64"}]
Run options: exclude {bolt: true}

All examples were filtered out

@Tames, was this with the latest RHEL 10 release that was made?

@Jason St-Cyr No, I'm not running it on RHEL 10, I'm just writing tests for RHEL 10.

I'm going to reach out to the folks working on PDK and see if we can figure this out... Also, for the download that didn't work, were you using this URL? • https://artifacts-puppetcore.puppet.com/v1/download?type=pdk&os_name=el&os_version=10&os_arch=x86_64&version=latest I just curl'd that from WSL (on my local Windows) with a valid API key and a signed EULA and it downloaded fine? I just want to double-check I'm reproducing the right scenario where you aren't able to download.

Yes, I'm using that link and using "license-id" and our license. It lets me in and gives that message.

Thanks @Tames, I've reached out to the Forge team to see if there's a reason that a license-id would find 'no resource' when an API key works, with the same link. I've also chatted with engineering about the outdated FacterDB, and it looks like that is indeed a missing piece that needs updating to fix, so I'll create a ticket for that team to address in an upcoming release.

Apologies, it looks like we jumped the gun on adding the download links, RHEL 10 packages will be released shortly as part of the next release.