For what seemed like good reasons at the time, we have decided to throw warnings in the job log under certain specific conditions. To that end, I’ve written a simple text filter which acts as a transparent pipe with the side effect of running Display().warning(message) on whatever text passes through it. Likewise, I’ve put together a very simple module which takes a single parameter, “msg”, which it sends to module.warn(msg), also with satisfactory results.
What drove me batty today was putting together a simple playbook to demonstrate and test these two assets. I could get them to work once, but subsequent invocations mysteriously failed to yield the desired bright purple warning messages in the job logs.
After trying lots of fruitless theories for far longer than I care to admit, it appears that Ansible, or rather ansible-playbook, or perhaps a particular callback(?) is very adept at tracking warnings that have already been emitted and goes to some lengths to ensure any particular warning is only issued once.
At least that’s my current theory. But I’ve had several others today, so I’m rather hesitant to say this is in fact what’s going on. I have not seen this documented, and Ansible and I have a long record of misunderstanding how the other works.
Can someone who knows please say for certain whether this “only emit a given warning once” apparent behavior is the correct interpretation?
So why post here in Collection Development rather than Get Help ? Both the filter and the module are in a local collection, and their reason for being is also in this collection. This is an exercise in transitioning from legacy roles and corresponding services to newer ones.
More specifically, we have a role that interfaces with our legacy monitoring system. It’s slated to be replaced by a new role which works with a new monitoring system. As a stop-gap measure, in a rush, under circumstances not of our choosing, we added a “thing” to the end of the old role which makes a corresponding call to the new one. That is, when our old plays create a maintenance period on a set of hosts in the old monitor, we also get a corresponding maintenance period created in the new system “for free”.
Well, “for free” turns out to actually mean, “to be paid for later.” Later has come.
The plan now is to have the old role start to issue a warning whenever it’s called without the caller explicitly indicating whether the “chain to new role” (current default) behavior should be taken. Once those warnings are gone, we’ll start warning about anything still making calls to the old system. And after those are gone, we can mothball it for real. This should help us be aware of legacy usage, and - fingers crossed - avoid unnecessary breakage as this internal collection evolves.