Don't trust sellers! Automation is never 100% complete

Nobody can sell you a solution that satisfies all your needs. You can only develop it.

I had a workshop yesterday with a customer. We planned what to do this year. Automation was one of the most important topics, of course. We discussed integrating automation into the Ansible Automation Platform to enable everyone, even without deep IBM Power knowledge, to execute repeatable tasks just by clicking a button. My last question was: “How many years do you have till your pension?”

You may ask why I was so harsh. I'm sorry to tell you that there is no 100% solution for every need in your data center.

Tools

You know, I write a lot about Ansible. Some of you tell me they don’t want to use Ansible because everything is already scripted in a shell.

I don’t trust you if you say that EVERYTHING is scripted. Most of your tasks, or maybe the most important ones, are scripted. This is fine! Continue using your scripts! I script a lot and find KornShell the best scripting shell. One of my favorite amusements in my job is to write a shell one-liner with so many commands that it has two or three lines.

Maybe it will be a big surprise for you - I don’t use Ansible for everything. I use Ansible, shell scripts, Python scripts, Google Go programs, and even C occasionally. I have also been using Chef for a long time. Your task and the desired outcome define the tool you should use to automate.

Tasks

If we talk about deployment and server configuration, Ansible is my favorite. I use Terraform to deploy an LPAR in IBM Cloud PowerVS. I can use it in a PowerVC-managed environment I don’t have right now. But there are no Terraform plugins for Power HMC.

Ansible is not always the tool of my choice for deployments. Sometimes, I work in older environments. If you still have a SAN switch with FabOS 7, you can’t use Ansible. You can develop scripts - in Shell or Python. The scripts can be used later in Ansible playbooks, but you must create them first.

You can create your own Ansible collections for some of the tasks. I created collections for PowerHA for AIX, AIX deployments in Microsoft Azure, and other use cases.

Is Ansible suitable for “Day 2” operations? Yes, it is! Maybe not for every task. I wouldn’t create a playbook to extend a filesystem because it is easier and faster to do with a command. But I can imagine there can be such a use case when the playbook to extend a filesystem would be feasible.

A similar example is a role or playbook for creating a mksysb backup. I published it in the newsletter this year. Basically, it is a single command that needs to be executed. But there are nuances. For example, if I create mksysb for a VIOS, I want to execute viosbr first. Or I want to be sure that all servers have /etc/exclude.rootvg. Can I do the same with a shell script? Certainly! I did it for years. But if I don’t have the script or I want to integrate my mksysb in another Ansible playbook, it is easy to create it in Ansible.

There are many such “Day 2” operations, where I ask myself daily if it makes sense to automate in Ansible or Shell or drop the task and not automate at all. One example is the VIOS update. I haven’t automated VIOS updates for years. There is documentation, and you can execute command by command without automating. I wanted to have more control if something went wrong!

Now I have my VIOS update playbook. With it, I have performed literally thousands of VIOS updates in the last two years. Is it perfect? Of course not! There is always a place for improvement. One of the possible improvements we discussed yesterday.

Here is the clue. Don’t try to automate everything, and never trust people who promise to automate everything. Choose just ONE task and automate it. If it works, even imperfect, choose another task and automate it. If you don’t know which task to automate, read my newsletter and choose one you like.

Outcomes

If we talk about automation, we usually understand it as something with a result - install a new server, update it, or create a backup. There are many tasks where you don’t have such clear outcomes. What is the outcome if I want to establish performance monitoring in my environment? I can automate the deployment of the monitoring software and agents. But I can’t monitor performance with Ansible. Either I must look regularly at the performance dashboards, or I must define thresholds. In the second case, I can create playbooks to automatically react to the alerts.

Two years ago, IBM Champion Nicolae Chirea published articles on how he creates a small SQLite-based CMDB with Ansible. From my point of view, this is another use case with no really definable result. The information in the CMDB must be updated regularly. I do such tasks with pure Python scripts. But it is my preference.

As you can see, I usually don't use Ansible if I need some sort of “dashboard”—either web or database—with regularly updated information. It doesn’t mean this is the only correct way of doing it. You can remember The Foreman (commonly known as Red Hat Satellite), which can collect data from the hosts using Ansible facts and build beautiful dashboards.

Support the Power DevOps Newsletter!

Upgrade to our paid tier to unlock every article in the archive. Become a Founding Member for a little extra and book a 1-to-1 coffee chat with Andrey Klyachkin.

Why do I write about this?

There are many ways to Rome. Analyze your tasks and desired outcomes, and choose the right tool for them! Ansible is a wonderful tool that is easy to learn and implement, but no tool can do everything for you.

Do you use Ansible or other tools?

Did you solve some problems in your IBM Power environment last year?

Do you have brilliant ideas on how to make the world better?

Share it with others and submit your presentation for the Common Europe Congress 2025 in Gothenburg, Sweden!

Have fun!

Andrey

Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.

Follow me on LinkedIn, Twitter and YouTube.

You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.