ansible/ansible — pull request #9448 by jessedhillon (2014-10-29 11:26:47+00:00)
Title: Adds `list_behaviour` to concat unique list items

Just as `hash_behaviour` determines whether clashing key names pointing to `dict` instances should result in those instances being merged or replaced, `list_behaviour` (valid values: `merge`, `replace`) determines whether keys pointing to `list` instances should result in the unique elements of the lists involved being extended into a new list. Uniqueness is done by trivial comparison (using `list.__in__`)

Having seen the comments about `hash_behaviour` it seems to me that the ansible team has a use model in mind which is philosophically opposed to the idea that different roles could provide variables definitions which combine to create a coherent description of the deployment target. However, it seems to me that without merging of `dict` and `list` instances one ends up repeating themselves endlessly, by *e.g.* writing tasks like "install packages via apt" over and over, varying only the `with_items` argument. I don't understand why it's considered undesirable that a `common` role define a `apt_install_packages` list variable, and a `worker` role (which includes `common`) define the same variable containing only those packages, additional to the ones in `common`, to be installed:

In `roles/common/vars/main.yml`:

``` yml
apt_install_packages:
- { name: "foo-package", version: "1.23" }
```

In `roles/worker/vars/main.yml`:

``` yml
apt_install_packages:
- { name: "bar-package", version: "2.34" }
```

That way the task `install apt packages` only needs to be defined in `common/tasks/main.yml` and when the role is included it will run against the `apt_install_packages` list which is the accumulation of all packages that all roles need to request. Seems like a simple way to cut down on code and improve the comprehensibility of a playbook. If apt package installation fails, you only need to check the one task defined in `common`.

I hope this feature gets pulled and supported, it's really makes ansible manageable for me. I'd love to know what it is about the ansible philosophy that I'm missing, which is making it so that I feel this feature is needed but the devs feel this is contrary to the ideal use case.