Navigation

I was kicked out of the Ansible community, presumably for asking the wrong
questions, and therefore I have no interest in developing this adapter
anymore. If you use it and have changes, I will take your patch.

The following steps should get you up and running quickly with reclass and
Ansible. Generally, we will be working in /etc/ansible. However, if you
are using a source-code checkout of Ansible, you might also want to work
inside the ./hacking directory instead.

Or you can also just look into ./examples/ansible of your reclass
checkout, where the following steps have already been prepared.

The integration between reclass and Ansible is performed through an adapter,
and needs not be of our concern too much.

However, Ansible has no concept of “nodes”, “applications”, “parameters”, and
“classes”. Therefore it is necessary to explain how those correspond to
Ansible. Crudely, the following mapping exists:

reclass concept

Ansible concept

nodes

hosts

classes

groups

applications

playbooks

parameters

host_vars

reclass does not provide any group_vars because of its node-centric
perspective. While class definitions include parameters, those are inherited
by the node definitions and hence become node_vars.

reclass also does not provide playbooks, nor does it deal with any of the
related Ansible concepts, i.e. vars_files, vars, tasks, handlers, roles, etc..

Let it be said at this point that you’ll probably want to stop using
host_vars, group_vars and vars_files altogether, and if only
because you should no longer need them, but also because the variable
precedence rules of Ansible are full of surprises, at least to me.

The attentive reader might stumble over the use of singular words, whereas
it might make more sense to address all mailserver*s* with this tool.
This is convention and up to you. I prefer to think of my node as
a (singular) mailserver when I add mailserver to its parent classes.

Every entry in the list of a host’s applications might well correspond to
an Ansible playbook. Therefore, reclass creates a (Ansible-)group for
every application, and adds _hosts to the name. This postfix can be
configured with a CLI option (--applications-postfix) or in the
configuration file (applications_postfix).

For instance, the ssh.server class adds the ssh.server application to
a node’s application list. Now the admin might create an Ansible playbook
like so:

There’s a bit of redundancy in this, but unfortunately Ansible playbooks
hardcode the nodes to which a playbook applies.

It’s now trivial to apply this playbook across your infrastructure:

$ ansible-playbook ssh.server.yml

My suggested way to use Ansible site-wide is then to create a site.yml
playbook that includes all the other playbooks (which shall hopefully be
based on Ansible roles), and then to invoke Ansible like this:

ansible-playbook site.yml

or, if you prefer only to reconfigure a subset of nodes, e.g. all
webservers:

$ ansible-playbook site.yml --limit webserver

Again, if the singular word webserver puts you off, change the
convention as you wish.

And if anyone comes up with a way to directly connect groups in the
inventory with roles, thereby making it unnecessary to write playbook
files (containing redundant information), please tell me!

However, in resolving this, Ansible casts everything to a string, so in this
example, dict_reference would be the string-representation of the
dictionary under the motd key [1]. To get at facts (such as
ansible_fqdn), you still have to use this approach, but for pure parameter
references, I strongly suggest to use reclass interpolation instead, as it
supports deep references, does not clobber type information, and is more
efficient anyway:

parameters:
motd:
greeting: Welcome to {{ ansible_fqdn }}!
closing: This system is part of ${realm}
dict_reference: ${motd}

Now you just need to specify realm somewhere. The reference can reside in
a parent class, while the variable is defined e.g. in the node definition.

And as expected, dict_reference now points to a dictionary, not
a string-representation thereof.

I pointed this out to Michael Dehaan, Ansible’s chief
developer, but he denied this behaviour. When I tried to provide further
insights, I found myself banned from the mailing list, apparently because
I dared to point out flaws. If you care, you may look at
https://github.com/madduck/reclass/issues/6 for more information.