Hi, Please give my module a try:
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ł: > > I've been stumbling over this, too. According to this: > > > 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 > developer-supplied playbooks inherit the new implementation; > - there's no dodging around like fools trying some kind of staged-commit > morris-dance to get such a change like that through the CI gating of, > 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" > --- > - name: undeploy a container > include: undeploy_v{{ versions.old }}.yml > > - name: deploy a container > include: deploy_v{{ versions.new }}.yml > ]]] > > By manipulating the variables versions.old and versions.new, we can > potentially manage a change of container technology (I'm using this as a > concrete example; there are others) without component development teams > needing to touch their own playbook repos. > > > > The situation is still complex, but it's a manageable level of complexity. > > However, without j2 expansion of the includes: we're left with this, which > is something of a sprawling mess: > > [[[ > A rather more clunky version of the abstract playbook > Delegate out to the correct implementations > --- > - name: undeploy a container, v1.1 > include: undeploy_v1.1.yml > when: versions.old == 1.1 > > - name: undeploy a container, v1.2 > include: undeploy_v1.2.yml > when: versions.old == 1.2 > > - name: undeploy a container, v2.0 > include: undeploy_v2.0.yml > when: versions.old == 2.0 > ]]] > > This is rather more error-prone and laborious. > > > > Now, the helpful note in the documentation suggests that I should be > looking to restructure my playbooks to be more class/role oriented. What > is more class oriented than supplying multiple contrete implementations of > the lifecycle API, I'm not clear; and achieving this through roles would > seem to involve jumping through several mental hoops about what a > particular role represents ("hosts that were running service X version Y > that needs to be removed from there" - yuck). > > > Suggestions are very welcome! > > Cheers, > jan > > > -- > [email protected] <javascript:> http://ioctl.org/jan/ Short, dark, ugly: > pick any three > Goth is the new black. > -- 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/5ea39207-9828-4895-9050-66a81c3b3e42%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
