# More on the "include : {{ foo }}.yml" matter - a long and concrete example

**URL:** <https://forum.ansible.com/t/more-on-the-include-foo-yml-matter-a-long-and-concrete-example/17231>\
**Category:** Ansible Project\
**Created:** [January 9, 2015, 3:39pm UTC](https://forum.ansible.com/t/more-on-the-include-foo-yml-matter-a-long-and-concrete-example/17231 "2015-01-09T15:39:58Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jang](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jang](https://forum.ansible.com/u/jang)\
**Post date:** [January 9, 2015, 3:39pm UTC](https://forum.ansible.com/t/more-on-the-include-foo-yml-matter-a-long-and-concrete-example/17231/1 "2015-01-09T15:39:58Z")

</div>

I've been stumbling over this, too. According to this:

[http://docs.ansible.com/playbooks\_roles.html#task-include-files-and-encouraging-reuse](http://docs.ansible.com/playbooks_roles.html#task-include-files-and-encouraging-reuse)

and specifically, this:

[[[  
Note

You can not conditionally path the location to an include file, like you  
can with vars\_files. If you find yourself needing to do this, consider how  
you can restructure your playbook to be more class/role oriented.  
]]]

dynamic includes like this can't be done. (The very helpful halberom on  
#ansible suggested this had been removed due to "security concerns".)

Let me explain why I was trying to do this, and why something like this  
would be useful. I've broken the following bits of the explanation down  
into small chunks; without that it's something of a wall of text.

I've got a bunch of development teams who are writing playbooks. They're  
each deploying multiple services which, taken as a whole, comprise a large  
and complex application.

(We may very likely be using multiple git repos to manage those playbooks,  
for administrative reasons such as managing the gerrit review workload.)

Each service component will likely be deployed into some kind of  
"container". Those containers might be python venvs; or chroot  
environments; or docker containers, etc.

Now, I'd like my developer groups to be able to lean upon  
centrally-managed tasks to do things like "prepare a container", "install  
software X into container Y", and so on.

So, there's kind of a high-level operational/deployment API we're talking  
about, that development teams can lean on.

The use of task inclusion (with parameterised tasks that take an  
appropriate set of variables) looks ideal to achieve this.

The advantages of this are that:

- we then have a single place to update our choice of container technology implementation  
- developer groups can write playbooks to that abstract API  
- vitally, we can make a change to the central implementation and all  
&nbsp;&nbsp;developer-supplied playbooks inherit the new implementation;  
- there's no dodging around like fools trying some kind of staged-commit  
&nbsp;&nbsp;morris-dance to get such a change like that through the CI gating of,  
&nbsp;&nbsp;potentially, multiple git repos.

So far, so reasonable, I think; it requires a bit of up-front planning  
(although that's not a bad thing) to understand what kinds of operations  
the lifecycle comprises - and it's one way to tackle the large amount of  
complexity something like this has.

But, when it comes to an upgrade of an \*already-installed\* system, the  
situation is a little more interesting: in particular, we'll know about  
the version we were going \_from\_, and the version we're moving \_to\_. It's  
quite natural to write common playbooks that create and destroy  
containers, or deploy software into them, etc, as a set.

An upgrade, then, needs to pick an appropriate version of the central API  
implementation for different tasks, eg, as a quick sketch:

[[[  
This abstract playbook "delegates" to two separate concrete  
implementations!  
In practice, I'd expect to have high-level playbooks that wrap  
a single conceptual task like "do X"/"undo X"

---

<div class="post-metadata">

**Author:** ![Grzegorz\_Nosek](https://avatars.discourse-cdn.com/v4/letter/g/5daacb/32.png) [@Grzegorz\_Nosek](https://forum.ansible.com/u/Grzegorz_Nosek)\
**Post date:** [January 27, 2015, 6:28pm UTC](https://forum.ansible.com/t/more-on-the-include-foo-yml-matter-a-long-and-concrete-example/17231/2 "2015-01-27T18:28:12Z")

</div>

Hi,

Please give my module a try:

[https://github.com/gnosek/ansible-play](https://github.com/gnosek/ansible-play)

You should be able to do something like this:

tasks:

- name: upgrade container  
play:  
tasks:

- name: undeploy a container  
include: undeploy\_v{{ versions.old }}.yml

- name: deploy a container  
include: deploy\_v{{ versions.new }}.yml

Best regards,  
Grzegorz Nosek

W dniu piątek, 9 stycznia 2015 23:45:14 UTC+1 użytkownik Jan Grant napisał: