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.
On Thu, Dec 21, 2017 at 11:06 AM, Olivier Cervello < [email protected]> wrote: > 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). > > --- > > - name: Test > hosts: all > vars: > files: > - src: /etc/hosts > dest: /tmp/2 > state: link > - src: /etc/fstab > dest: /tmp/1 > state: link > - src: /etc/hostname > dest: /tmp/3 > state: link > - path: /etc/nginx/nginx.conf > state: absent > > Only the following syntax can allow to run multiple tasks that have mixed > params (and *null* params in some case): > > - file: > args: "{{ item }}" > with_items: "{{ files }}" > > If I used the syntax you offered above, I would need to specify defaults > to None for all the arguments: > > - file: > src: "{{item.src | default(None) }}" > dest: "{{item.dest | default(None) }}" > path: "{{ item.path | default(None) }}" > state: "{{ item.state }}" > with_items: "{{ files }}" > > The last syntax is worse because: > > - it removes the original task defaults and you have specify them > AGAIN by looking up documentations and setting every task args to their > original defaults. > - if I need to use one of the other resource arguments (say `mode`, I > have to modify my task to add it, when the first syntax gives you a task > that work with any argument defined in the `file` resource...) > > > *Another example with EC2 provisioning:* > > After deprecation, I am again forced to explicitly define all the `ec2` > task variables (if I want automation flexibility in `group_vars`): > > - name: Provision EC2 instances > ec2: > key_name: "{{ item.key_name }}" > instance_type: "{{ item.instance_type }}" > image: "{{ item.image}}" > wait: "{{ item.wait }}" > exact_count: "{{ item.exact_count }}" > count_tag: "{{ item.count_tag }}" > vpc_subnet_id: "{{ item.vpc_subnet_id }}" > assign_public_ip: "{{ item.assign_public_ip }}" > region: "{{ item.region }}" > group: "{{ item.group }}" > instance_tags: "{{ item.instance_tags }}" > instance_profile_name: "{{ item.instance_profile_name }}" > volumes: "{{ item.volumes }}" > with_items: "{{ ec2_instances }}" > > Before the deprecation, we could have* much simpler tasks*: > > - name: Provision EC2 instances > ec2: "{{ item }}" > with_items: "{{ ec2_instances }}" > > > *Summary* > The Ansible core team has not specified the reason it consider this > practice unsafe. If an attacker can temper with the `group_vars`, he can do > it in both case (this syntax enabled or not). Deprecating this also > violates Python principle of simplicity. IMHO, this is a step backwards for > Ansible. > > The DevOps engineer or the developer automating the solution should worry > if it's safe / unsafe, should own the deployment code / deployment > variables and has to make sure those are stored in a safe place. I don't > think it's the responsibility of Ansible to prevent this behaviour. > > Please explain how you consider this last syntax as more *unsafe* than > the first syntax, and in what conditions. > > Thanks, > > *Olivier Cervello* > *Cloud DevOps Infrastructure Engineer* > *Google Inc.* > > On Tuesday, December 19, 2017 at 2:21:28 PM UTC-6, James Cammarata wrote: >> >> 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: >> <your var list here> >> >> >> >> James Cammarata >> >> Ansible Lead/Sr. Principal Software Engineer >> Ansible by Red Hat >> twitter: @thejimic, github: jimi-c >> >> On Thu, Mar 16, 2017 at 6:02 AM, Michał Czeraszkiewicz <[email protected]> >> wrote: >> >>> I'm trying out this playbook: >>> >>> --- >>> >>> - name: Test >>> hosts: all >>> vars: >>> link_list: >>> - src: /etc/hosts >>> dest: /tmp/2 >>> state: link >>> - src: /etc/fstab >>> dest: /tmp/1 >>> state: link >>> - src: /etc/hostname >>> dest: /tmp/3 >>> state: link >>> - src: /etc/resolv.conf >>> dest: /tmp/4 >>> state: link >>> tasks: >>> - file: >>> args: "{{ item }}" >>> with_items: "{{ link_list }}" >>> >>> >>> >>> I get the following message: >>> >>> [DEPRECATION WARNING]: Using variables for task params is unsafe, >>> especially if the variables come from an external source like facts. >>> This feature will be removed in a future release. Deprecation warnings >>> can be disabled by setting deprecation_warnings=False in ansible.cfg. >>> >>> Why is that so? >>> >>> I think the usage of args is more elegant and feature proof (I don't >>> need to extend my role when parameters change in the module) than >>> specifying the arguments by hand. See example here >>> <https://github.com/geerlingguy/ansible-role-elasticsearch-curator/pull/10/files> >>> . >>> >>> -- >>> 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/ms >>> gid/ansible-project/8de82682-1289-467d-907d-b2b5272045a9% >>> 40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/8de82682-1289-467d-907d-b2b5272045a9%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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/24177474-ff43-4f01-9f7c-ed1951b13665%40googlegroups. > com > <https://groups.google.com/d/msgid/ansible-project/24177474-ff43-4f01-9f7c-ed1951b13665%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Matt Martz @sivel sivel.net -- 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/CAD8N0v8ZUj8fNJXiS8ZuOi-1xUoEn5MeeYB4fn-8e01BRjCH5g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
