maybe something with mocked facts updating!

What I'm seeing is that the issue seems to be with expectations around things like "$facts['os']['family']"

https://gist.github.com/wyardley/adc6ca4ba28dc79cffc79acf3c8caade < the tests made pending in the diff are the ones that fail. the code itself (see below the diff for a snippet of one relevant section) seems Ok?

unrelated: anyone seen a case where the changelog generator associates an issue with the wrong release? (in this case, https://github.com/voxpupuli/puppet-rabbitmq/issues/930 is getting attached to 12.1.0 (last release) vs upcoming 13.0.0

(if the 'bug' label is not attached, it's in the right release, but not in the fixed bugs section anymore)

https://github.com/voxpupuli/puppet-rabbitmq/blob/master/spec/classes/rabbitmq_spec.rb#L204 that should never be true

all the listed operating systems use systemd

yeah, was wondering about that - may be able to simplify some of the code now that everything is using systemd

yep

https://github.com/voxpupuli/puppet-rabbitmq/blob/master/spec/classes/rabbitmq_spec.rb#L9 and rename facts to os_facts

to not confuse it with

let :facts

just in there and in the let block, right?

oh, ok, do have to update all the places where facts is used

I guess I can see some benefit in keeping the systemd conditional and the tests for it, even though no supported OSes don't use systemd

FreeBSD and OpenBSD are listed as supported, I think, whether or not we unit test them

if we get this other stuff sorted out, I can see how much effort it would be to get tests working for FreeBSD 13. Looks like there may be some code changes needed anyway, so that would be a win / win, and we'd have those specs get run again

https://github.com/voxpupuli/puppet-rabbitmq/pull/932 open to suggestions on making the conditionals less messy. this would also implement bastelfreak's suggestions for os_facts

ewoud: Zhenech https://www.githubstatus.com/incidents/nf7s6933tnn8 I am really looking forward to the post mortem report next month

With data in modules, is it an antipattern to have the default for a module param defined both in the class spec and in, e.g., data/common.yaml? Ran into a confusing case from that happening, and only figured it out by grepping for the parameter name

I would only put it in one place yeah

if without further config one of the places already gets ignored (the class spec), I'd say, why put a copy there then

wby: best practice is to have the defaults in init.pp

and if required, move as few data as possible into hiera in modules

bastelfreak: so would you say removing it entirely from data/common.yaml is the right answer?

yes!

and I can explain it :D

if the data moves to a puppet clas, puppet-strings is able to pick it up and add it to the reference.md

Looks like https://github.com/voxpupuli/puppet-rabbitmq/commit/e90dcbdeb3e8d0d0fe13f1f089a8a832d8435786 moved it entirely into data :/

That's going to be an awful pain to unwind....

yeah I also did it a few times in the past :(