Perth, Western Australia - 6th to 10th January 2014
With modern system configuration management software, such as the popular Salt, Puppet, Chef, and Ansible, operators generally target configuration (behaviour) at hosts. In homogeneous environments, this makes sense, but when the environment is of heterogeneous nature, this approach quickly gets unmanageable.
If you maintain dozens and dozens of behavioral roles with only few nodes assigned to each, or if your infrastructure configuration special-cases hostnames, then rejoice, for here is help.
And even if your nodes come and go every day, and/or have numeric hostnames (aw!), here is an alternative paradigm to describe your infrastructure for consumption by the tools that manage your cloud or the machines in your rack.
reclass is a tool conceived during a massive migration from CFengine to Puppet, which received a complete rewrite in 2013 and is now faster, more predictable, more powerful and usable with Puppet, Salt and Ansible. Small adapters can be easily written (Python) to support other tools. reclass stands for "recursive external (node) classification".
reclass allows you to take a host-centric perspective of your infrastructure and mix and match behaviour in a hierarchical fashion, multiple inheritance included and encouraged.
reclass predates and inspired Hiera, and it's leaner and meaner. And written in Python, made to interface with whatever keeps your machines the way you want them.
Your webservers run Fedora while your mailservers are Debian machines, except one? Your nodes in Wellington should pull from a local distro mirror, while those in Perth should talk to Singapore, except three? And one webserver should listen on port 81 instead? All of those cases are one or two lines of YAML away.
reclass works by merging data during a recursive descent of a class hierarchy. Data in more specific classes overwrite data in more generic classes, naturally, and parameters may reference each other, independent of their position in the hierarchy. Recursive loops won't create galactic black holes.
How about pushing a backport to all your Debian oldstable nodes except those in Melbourne? Two lines of YAML…
reclass hooks into the provisioning systems and can serve them all, simultaneously, from the same database. This is very useful during step-wise migrations from one provisioning system to another, or when multiple systems are used in parallel, such as Salt and Ansible. If you need to reflect a change in your infrastructure, you do it once, only. In reclass.
And even with a single system, reclass allows you to keep everything in one place: roles, applications, parameters, and relationships. Defaults and exceptions, everything is tracked exactly in one place and exactly where you'd expect it.
You want port 4949/tcp open on all machines that the Munin server polls, without going back and forth between hosts and without time-delays? Use reclass!
I'll give a quick introduction to the concepts underlying reclass — which aren't hard to comprehend — and then put it to use, designing a fictitious use-case however complex the audience wants it to be, on the fly.
Martin F. Krafft (or "madduck", as he's commonly known) is a dedicated Debian developer with a Ph.D. in open-source method diffusion and adoption behaviour. As a freelance consultant and trainer, he teaches network security and privacy protection to a professional audience.
Martin came to Debian in 1997 and has since been helping with user support, public representation, security issues, quality assurance, integration tasks, as well as the maintenance of packages, such as mdadm, hibernate, and logcheck. He is the author of the book _The Debian System_ (http://debiansystem.info/).
Martin maintains servers for several NGOs, assists with IT management at the University of Zurich, and runs `madduck.net`, a you-want-it-you-get-it, non-profit and free service for currently 230 users.