So, recruiters, you’re looking for somebody with ten (10) years of Ansible experience? Here I am. On 2012-06-06, ten years to the day, I wrote my first blog post on Ansible.

I’m certainly not the only one who’s worked with the Ansible software so long, and there are people who’ve done a lot more for its community, but I thought I’d share some of the things I did or experienced along the way.

The first written record on Github of me contributing to Ansible is dated July 20th, 2012. (I may have had previous interactions on the Ansible mailing list but it’s impossible for me to search through that.) I provided the world with a few small modules and lookup plugins, but my pièce de résistance has always been the documentation generator: modules (and later plugins) have their documentation inline, and this is extracted on-the-fly with ansible-doc(1). The official module documentation pages, e.g. get_url are generated from the same source. Back then, running ansible-doc -l to list modules and their single-line description was fast, but Ansible meanwhile has over 6,500 modules and having to instantiate them all to access the DOCUMENTATION variable hurts. I work around this deficiency by recommending ansible-doc -l > doc and grep(1) through that.

Contributing modules used to be fun, but hearing years later that ini_file doesn’t work when a section is empty or whatnot, just makes me yell “well then just don’t leave it empty!” into the void. Maintainers know what suffering is, and I’ve had a minuscule amount of it. On the other hand it’s a confirmation that the code is being used. (Nobody’s ever complained about my mqtt notification module…)

There have been ups and downs. One of the “ups” was when Michael invited me to the very first Ansible Fest in Boston in 2013. There I also had the distinct pleasure of meeting Seth Vidal with whom I discussed creating local facts. Sadly, Seth passed shortly thereafter – a loss to the community.

Another definitive “up” for me is how I won the argument against Michael that module docs should have formatting in them. A very simply C(constant) type syntax was invented, which he didn’t want, but I won. I’ve dined out on that story and strongly hope he has no hard feelings about it. :-)

I’ve previously written about how I care about Ansible, and I still do. I greatly enjoy teaching students about Ansible and how to use it, and while I actively stopped doing so for Tower/AWX in 2020, several hundred people have meanwhile listened to me be mostly positive about the rest, and we went a step further and created a more advanced course.

One of my infamous “downs” was the sudo cake fiasco which gathered some notoriety and has even found mention in books. In terms of embarrassing mistakes in my career, it certainly takes the cake. Today, still, after countless hours of therapy I use the cake metaphor to teach students that we have to respect config management and that running modules with root privileges on hundreds of machines can be exciting. An upside of this fiasco: it lead to Brian (who read the post back then) suggesting template validation, meanwhile also available on a bunch of other modules, and while I like saying validation is for wimps, students do always realize I’m poking fun at myself in saying so!

I regret having had to abandon work I began on an Ansible booklet which could have become a good bit of (printed) documentation.

I couldn’t find the time to complete the effort and then forgot about it. Others have done stellar work on documenting Ansible: Jeff Geerling with his book Ansible for DevOps and Lorin Hochstein, René Moser, and Bas Meijer with their book Ansible Up & Running which I’ve had the honour of reviewing for the 2nd and 3rd editions.

I’m no fan of cowsay and coined the configuration NOCOWS=1, but I did write up a cow and bull story explaining their Ansible-related background. In my Ansible trainings I install a self-written cow server called cattled for an exercise and hope that will aid in reinstating me amongst cow lovers. Apropos cows: I’m a bit chuffed to report I’m the person who convinced O’Reilly to turn the cow around on the cover of “Up and Running”’s 3rd edition so that it matches the direction in which cowsay cows look.

We invented the {{ ansible_managed }} variable for templates back in 2012 as a mechanism with which I can mark a file as being managed somewhere else, hopefully preventing administrators in editing this file. The default value has always been configurable and was broken during some misunderstanding. Anyway, it can still be configured. Ten years later I stumble across official documentation which demonstrates how to couple that with {{ comment }} to make it output over several lines. The times I’ve wanted that … It turns out the idea was part of the PR introducing the comment filter, so thank you Jiri!

It’s been a bit of fun.

I decided to ask my followers whether I have somehow influenced/improved/deteriorated their lives in some way with my Ansible work, and these are some (partially abbreviated) responses I got:

• “I started automating stuff with Ansible because of your blogposts years ago” – Hagen
• “You made my life as admin easier. And while I can only write little things in Ansible, it really helps me.” joanna
• “I’m learning about your contributions every week. Did not know that you invented ansible_managed or the dig-lookup. So thank you!” – FiLiS
• “Since you’re responsible for ANSIBLE_NOCOWS=1, I’d say it did, yea.” Armin
• “I first heard about Ansible through one of your first blog posts.” Serge
• ”.. your blog posts at the time really showed how easy it was to get started ..” Vincent
• “There are only a few devs who I can almost guarantee will show up in my Google results when deep into a weird Ansible playbook… and you’re one of them.” Jeff
• “Your impact is obvious to anyone who looks.” Greg
• “Your blog posts and presentations were definitely inspiring.” – René
• “Your talk about Ansible at OSDC years ago got us to give it a try at Sipgate (and move away from puppet). Today, Ansible powers large parts of our deployments and system/network infrastructure.” Rudolph
• “Somewhere early 2012 you tweeted about Ansible [..] which turned out to have a massive impact on my working and personal life which I never could have imagined.” - Ton (in a long email)
• “i think it was your tweets and blogging about ansible that made me aware of it, and it was just what i needed (just use ssh, agentless, with check and diff modes). … ansible was soon adopted by my colleagues and it became the standard config management tool in cambridge university information services” Tony

Sadly some people didn’t properly read my query (I think) and just sent a few dozen “Ansible sucks” and “fuck YAML” my way, so my expectations in that regard were also met.

It gives me a warm, fuzzy feeling that you might in some part of the world be using some small portion of Ansible in which I muddled, back in the time. Enjoy it. And what really gives me warm feelings is that along the way I’ve met a number of people (in real life) whom I enjoy encountering when I can.

And why did I even glance at something as unfinished as Ansible was at the time, those ten years ago? I worked in a project in which I wanted to automate deployment of a number of DNS servers, and I disliked the tool I had to use so intensely, that I grasped at any straw I could find. That’s my story, and I’ve no regrets.