[dkoeji89oe]

That sounds a lot like "if my code is bad, I'll find out when it breaks in production, so why test?". Tests allow you to make changes to your ansible configs, then test that the ansible config works correctly before you apply it in production.

[devn0ll]

"That sounds a lot like "if my code is bad, I'll find out when it breaks in production, so why test?""

Oh no defintely not, no I mean you test and build your ansible and cluster stuff in Development / Acceptance. We create our monitoring checks there as well. And when all that is done and "green": we go to production.

BTW. Testing your cluster is something you do in dev/acc before you go to prod. And Ansible / monitoring already shows you problems in those pre-production stages.

What added benefit is there for Goss in that scenario?

[dkoeji89oe]

...you run goss during the process of developing your ansible roles.

Ansible roles are code. Goss allows you to test that code well before you're attempting to create real systems. Real systems include dev/acceptance envs where you're launching your application.

The value isn't in "Did this specific run of ansible work?" but earlier in the process --"After I made changes to my ansible role, does it still meet my requirements?"

[devn0ll]

aaah, ok now my veil before my eyes is clearing up.

So like in: I change a small thing in ansible, perhaps even in an unrelated role, and then check if all is still as I expect it?

[dkoeji89oe]

exactly.

this is particularly important if you ever rely on 3rd party modules. a common pattern is to spin up VMs, apply config management, then validate config management as part of your infrastructure's ci process.