My usual selection mode is: is there a "supported" module, is there a module provided by the thing I'm managing, is there a voxpupli module, is there an "approved" module, is there a pdk module

i’m the same. just move PDK up to 2nd in that list

well, https://github.com/voxpupuli/beaker-rspec/pull/120 now passes on Ruby < 3.2 so that does mean better test coverage :)

Now that I think about it, it’s supported, approved, pdk, Vox. Outside of those things, I try not to use random modules on the Forge. I do know that Perforce is trying to clean up the Forge now. Waiting to see what that looks like.

And if the testing framework finally gets settled, and they make it a hard requirement, I’m sure there’ll be quite a bit of “scorched earth” at some point.

we've briefly chatted about Litmus vs Beaker at cfgmgmtcamp and I believe it should be fairly easy to align the two so that you can use the same syntax for both and they're really just libraries

my idea is that you start using native rspec matchers instead of apply_manifest() - so https://github.com/voxpupuli/beaker-rspec/pull/115 is roughly where I'd like to end up

and then write the same matcher but with a Litmus implementation

with that I think it'd be much smoother for users if PDK does decide to move back to Beaker

that’s a great idea.

As long as you stay away from

serverspec

, you'll be OK with that.

I was wondering when you were going to wake up and weigh in here. 😛

we do heavily rely on serverspec today, but I've wondered about multi server: I have seen an

on: host

parameter somewhere and wonder if that's actually implemented

I've thought about alternatives, because I do like some of the abstractions that it provides

I've used the multi server setup a lot with beaker , never could get it to work with Litmus but those attempts were a year or two ago

https://github.com/sensu/sensu-puppet/blob/master/spec/acceptance/00_backend_spec.rb - the majority of Sensu acceptance tests run a backend and agent as two distinct containers and run tests differently between the two including running specific serverspec tests on different containers.

https://github.com/sensu/sensu-puppet/blob/master/spec/acceptance/00_backend_spec.rb - the majority of Sensu acceptance tests run a backend and agent as two distinct containers and run tests differently between the two including running specific serverspec tests on different containers.

ewoud: we do some multinode testing here: https://github.com/voxpupuli/puppet-openvpn/blob/master/spec/acceptance/openvpn_spec.rb

bastelfreak: yes, but I get the impression that all the assertions are on the server node

still, good place to start to improve things

yeah true

https://github.com/voxpupuli/beaker/pull/1784 mhm I think it fails to provision the container

ewoud: oh maybe you need to switch to the ubuntu20.04 runner, like we did it in gha-puppet

or don't use centos7

before the sshd patch it worked on Ruby < 3.2

I think it reflects a past period where Puppet org was not communicating and developing together with Vox properly so to be fair i think divergence was inevitable. While there will be always be some difference in approach hopefully what we should be seeing out of the new ecosystem product team is a far greater focus to narrow these differences and reduce duplication of work by working together.

bastelfreak: so perhaps the sshd bit actually breaks centos 7?

mhm yeah possible

ewoud: did you test it before the sshd patch?

bastelfreak: yes, see the commit before last