On Thursday, January 25, 2018 at 9:17:31 PM UTC+1, Jim Ficarra wrote:
>
>  
>
>> *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 ;)

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/5b9f8893-561e-45f3-a638-0f9645a9859b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to