Earlier I wrote about external variable files when Smooge was asking how to protect against keeping confidential data in source control.
http://ansible.github.com/playbooks.html#external-variables-and-sensitive-data
The question came up today about conditionals, and how we could handle them. For the most part, I’m a big fan of separating the “what” from the “how”. This keeps syntax clean, as i don’t believe infrastructure recipes to look like a bunch of Perl code threw up all over them.
Here’s what I came up with:
https://github.com/ansible/ansible/blob/master/examples/playbooks/playbook3.yml
There are a few new concepts, for which I’ll probably document tomorrow for the web site.
B: Variables that bubble up from facter & ohai can be used to decide what to import. You have choice so you can install facter, you can install ohai, or you could install both. I test with both, actually. If you don’t have any of these, no errors will occur, you just won’t be able to substitute any variables in.
C: Per Seth’s suggestion, $foo is now a perfectly valid alias for {{ foo }}. This is not valid inside Jinja2 templates on the managed machines, though, so take note of that. I think this makes playbooks look a lot cleaner.
D: It’s legal to use variables to name your modules. This is kind of a ghetto-provider interface, and to be honest, I don’t expect it to be used at all. If we do it right, when aptitude comes along, we can put everything into a common module and rename the yum module to “package”.
Aside for some much overdo refactoring and logging upgrades this should be solid – the unit tests in source control also cover this now.
Another thing that I want to do, that I haven’t done tonight, is to give each task an “onlyif” clause, allowing the module to be easily skipped if an expression evaluates to false, ex:
onlyif: $facter_operatingsystem == ‘Debian’
That will further enhance things to be reasonably powerful in terms of capabilities, while still avoiding a lot of nesting and bloated syntax in the playbooks.
–Michael