I’m trying out this playbook:
`
I am also looking forward to understand why this is being deprecated. Also, if anyone knows an alternative, please do share.
It looks like this deprecation warning was first introduced via commit https://github.com/ansible/ansible/commit/e526743b4f91a571f48bff4280ce5e441f72a292#diff-76ffc0551f8cf3d6255500316568e60bR242 by jimi-c. The commit message/comment refers to a debate on whether to have this added to 2.0. Hopefully, if that discussion is captured in text somewhere, a link to that will help understand the reasoning behind.
We consider this unsafe due to the fact that, if the variable is based on a fact of some kind, your tasks could start doing unexpected or malicious things (in the event that the remote system is compromised in some way).
In your example, you could still simplify your task by simply restructuring it a bit:
- file:
src: “{{item.src}}”
dest: “{{item.dest}}”
state: link
with_items:
I’m sorry but your solution is very limited in scope, and not flexible at all (something we expect from modern automation software).
Example with file resource:
Let’s say I want 2 symlinks and a file to be removed, and don’t want to bother declaring multiple variables / tasks for it (after all, Ansible has one resource valid for both those actions, so I should be able to define a single variable, and a single task).
Instead of default(None) you should be using default(omit) it was designed exactly for this purpose, and will not override the default. In instructs ansible to not pass that provided argument on to the module.
Ok, but I consider this as a workaround and not a solution (cf. comment I wrote above).
with_items is acceptable in the situations where you intend to loop over items, not pass in variable that aren’t meant to be iterated over. This deprecation has implications for include_role and import_role where the task parameters certainly will come from variables.
An additional 2 cents - there doesn’t seem to be much offered in the way of alternatives - honestly with_items is not an appropriate alternative for use cases not involving iteration. What is Red Hat offering for an alternative other than with_items?
2 cts more here:
I’m in the same kind of headache with zfs module: the list of possible zfs properties depends on the zfs implementation, and is very long (seems like a bas idea to fix this list anywhere).
Most people need to set 1 or 2 properties, but some uses need much more…
And I really think that if an attacker can write in ansible’s inventory… I’d consider all systems manageable from ansible as corrupted. I think about it like any program’s config: the program should reject invalid items if possible.
In the zfs module’s case, it should implement thousands lines of code (with associated bugs) to be able to do this correctly (or not correctly…). The other option is to limit it’s functionnality to a little subset of what it can do today.
Same thing with cron module (a bit mode “workaround-able”).
The people (or program) responsible for inventory’s variable have to understand what they do, please don’t try to make ansible too much intelligent (KISS please 
Forgot a killer-feature of zfs: you can define your own properties… no one is able to list possibilities here.
Hello,
I agree that this is a needed feature that simplifies code and enhances readability. I opened a feature request to make this a configuration option rather than removing it, if they insist on deprecating it.
https://github.com/ansible/ansible/issues/42192
V.G.