Ansible Runner's run_async() -and maybe run() - seem not to be thread-safe
I observed an unexpected and wrong behaviour: Ansible Runner consecutive calls mess up when done too fastly.
A small piece of code, that works when the calls are not done too fastly:
def playbook_run(self, name, parameters):
# ...
kwargs = dict( # ...
runner_async_thread, runner_object = ansible_runner.run_async(
**{k: v for k, v in kwargs.items() if v is not None})
while runner_async_thread.is_alive():
# ...
In the failing call (not the first, and calls not done in the VMs naming order), I send this param:
{"username": "new_user", "target": "sever_003_linux"}
But the artifact's stdout file reports:
The offending line appears to be:
{"username": "operator", "password": "!", "target": "sever_003_linux"}05_linux"}
^ here
We could be wrong, but this one looks like it might be an issue with
unbalanced quotes. If starting a value with a quote, make sure the
line ends with the same set of quotes. For instance this arbitrary
example:
foo: "bad" "wolf"
Could be written as:
foo: '"bad" "wolf"'
My theory is that Ansible API is not thread-safe, as this site also mentions the same: https://jira.opencord.org/browse/CORD-922
They recommend to fork in order to avoid this, but I think this should be solved in the API, although, for now, I fixed it using that method, as I describe here: https://stackoverflow.com/questions/68982519/ansible-runner-consecutive-calls-mess-up-when-done-too-fast/68982761#68982761
Versions:
ansible-runner 1.4.6
ansible 2.9.6
python version = 3.8.10 (default, Jun 2 2021, 10:49:15) [GCC 9.4.0]
Could this also be the reason for the issue I opened? #807
Hi! Is this an issue anymore? Was it fixed by the fix for #807?