Ansible - The HowTo's

---
#	ANSIBLE_LOCALHOST_WARNING=false ansible-playbook test.yml
- hosts: 127.0.0.1
  connection: local
  gather_facts: no
  tasks:

  - set_fact:
      myList: [ 'a', 'b', 'c', '4', 'd', '9' ]
      groceryList: [ 'fruit', 'vegetables', 'milk', 'FAT', 'SALT', 'SUGAR' ]
      unhealthyFood: [ 'FAT', 'SALT', 'SUGAR' ]

  - set_fact:
      rejectSingleItem: "{{ myList | reject('search', '4') | list }}"
      rejectNonMatching: "{{ myList | reject('match', '[^a-z]') | list }}"
      healthyGroceryList_forLoop: "[ {% for item in groceryList if item not in unhealthyFood %}'{{ item }}'{{ ', ' if not loop.last else '' }}{% endfor %} ]"
      healthyGroceryList_reject: "{{ groceryList | reject('in', unhealthyFood) | list }}"

  - debug:
      var: "{{ item }}"
    loop:
      - rejectSingleItem
      - rejectNonMatching
      - healthyGroceryList_forLoop
      - healthyGroceryList_reject
...

TASK [debug] *****************************************************
ok: [127.0.0.1] => (item=rejectSingleItem) => {
    "ansible_loop_var": "item",
    "item": "rejectSingleItem",
    "rejectSingleItem": [
        "a",
        "b",
        "c",
        "d",
        "9"
    ]
}
ok: [127.0.0.1] => (item=rejectNonMatching) => {
    "ansible_loop_var": "item",
    "item": "rejectNonMatching",
    "rejectNonMatching": [
        "a",
        "b",
        "c",
        "d"
    ]
}
ok: [127.0.0.1] => (item=healthyGroceryList_forLoop) => {
    "ansible_loop_var": "item",
    "healthyGroceryList_forLoop": [
        "fruit",
        "vegetables",
        "milk"
    ],
    "item": "healthyGroceryList_forLoop"
}
ok: [127.0.0.1] => (item=healthyGroceryList_reject) => {
    "ansible_loop_var": "item",
    "healthyGroceryList_reject": [
        "fruit",
        "vegetables",
        "milk"
    ],
    "item": "healthyGroceryList_reject"
}

• The in test was added in Jinja2 2.10 (unfold Changelog or see changelog in release notes), so you may not be up-to-date.
• Check it :
  dpkg -l | grep jinja2

Examples below :

• are given in the context of ad-hoc commands, but you should get the idea very easily to use them in a play
• specify no inventory file, which is ok as long as its name can be determined implicitly (default name, default location, specified in a personal settings file, ...). Otherwise, specify it explicitly with -i :
  ansible -i myInventoryFile
• should also apply to the --limit directive

Target	Syntax	Comment
by name
a list of hosts	ansible host1,host2,host3
a list of hosts matching a regular expression	ansible '~server0[12]\.acme\.org'	matches server01.acme.org and server02.acme.org make sure you're not limiting the effective target with the ansible-playbook -l flag
by group
all hosts of a single group	ansible groupName
all hosts known to Ansible	ansible all
hosts of several groups	ansible group1:group2:group3	The colon : actually means a logical OR. This command above applies to any host belonging either to group1 or to group2 or to group3 When it comes to complex rules with intersections and exclusions (see examples), it may not be a REAL "logical OR"
hosts belonging to the 2 specified groups	ansible 'group1:&group2'	aka intersection of groups
by name + group
all hosts except those matching an expression	ansible 'all:!expression*' ansible 'groupName:!badHost'	can be an expression with a wildcard or a regular expression the whole !... string must be single-quoted (details)
all hosts of a group except several of them	ansible 'groupName:!~(host1|host2)'	~ is used to introduce a regular expression you get the idea to exclude as many hosts as necessary

- hosts: 127.0.0.1
  connection: local
  gather_facts: no
  tasks:

  - set_fact:
      fruits: [
        'apple',
        'orange',
        'banana',
        ]

  - debug:
      var: item
    loop:
      - fruits

  - debug:
      var: item
    loop:
      - "{{ fruits }}"

  - debug:
      var: item
    loop:
      "{{ fruits }}"

TASK [debug] ********************************************************************
ok: [127.0.0.1] => (item=fruits) => {
    "item": "fruits"
}

TASK [debug] ********************************************************************
ok: [127.0.0.1] => (item=[u'apple', u'orange', u'banana']) => {
    "item": [
        "apple",
        "orange",
        "banana"
    ]
}

TASK [debug] ********************************************************************
ok: [127.0.0.1] => (item=apple) => {
    "item": "apple"
}
ok: [127.0.0.1] => (item=orange) => {
    "item": "orange"
}
ok: [127.0.0.1] => (item=banana) => {
    "item": "banana"
}

- fruits

• this passes the string fruits, not the fruits variable
• use "{{ }}" to pass a variable

- "{{ fruits }}"

• the leading dash - introduces a list item
• _HERE_ it's a one-item list, and this item happens to be a list
• Anyway, this is why the loop turns only once and displays all fruits at once

"{{ fruits }}"

this is what we expected

So far, I've found no exception to this rule : when using fail, the playbook execution stops. Period.
However, I've been amazed once, when —despite fail— the execution continued (... or at least _seemed_ to continue). Here's what happened then :

1. RedHat.yml is a role task file having a fail task, everything should go extremely well
2. the role RedHat.yml belongs to is applied by myPlaybook.yml
3. I run myPlaybook.yml on a group of hosts (myGroup has MANY hosts) :
   ansible-playbook myPlaybook.yml -l myGroup
4. the execution starts normally, I can see a series of expected fatal: [hostname]: FAILED! => {"changed": false, "msg": "Execution stopped on purpose for whatever reason"}, then the output continues with the following tasks ()

Explanation (this is highly specific to my context / code) :

1. when myPlaybook.yml starts running the role having the RedHat.yml task file, it starts executing main.yml
2. main.yml makes a conditional include_tasks of RedHat.yml, meaning some hosts get it, some don't. This is where the trick happens :
   • RedHat.yml is included by Red Hat servers
   • but there is also Debian.yml, with a similar set of tasks (hence tasks names) for Debian servers
3. the hosts who actually included RedHat.yml fail as expected (and are removed from the list of the playbook targets)
4. the other hosts continue normally, which is what I can see
   the tasks running at that time are not from RedHat.yml anymore but from Debian.yml
5. reasons why I've not been able to see what was happening :
   • large number of hosts in myGroup : the execution lists all of them and scrolls fast
   • cryptic hostnames : pretty difficult to spot that some hosts have disappeared after the fail
   • identical task names in RedHat.yml and in Debian.yml : when the playbook execution showed the name of the task right after the fail, I thought the execution of the task I edited file continued.