Mainframe Storage

 View Only

It's funny how things work out sometimes

By Ian Wright posted Fri April 01, 2022 02:40 PM


And here I thought that I had a unique idea

Ansible VS Code Logo (tm) - Trademark of Red Hat, Inc. Used with Permission

For the bulk of my career at IBM (2002 through 2017) I was completely focused on Storage. It was, and is, extremely interesting but I always really wanted to go outside of that bubble and do more across the architecture.

So, over the past five years (today happens to be my fifth anniversary of departing IBM and working in a role as a Business Partner at Mainline Information Systems), I've spent lots of time going outside of my old bubble of IBM storage. One area that I've been very interested in has been Ansible®.

If you don't know about Ansible, I'm happy to help with that. It is a universal language for automation.  Whatever you have in your environment, you can automate it with Ansible. This is because it doesn't use agents. It simply connects to the devices, typically over SSH, but it can also use Winrm for managing Microsoft Windows systems. Finally, of course, it can interface with published APIs.

Behind the scenes, most of this stuff is programmed in Python (PowerShell in Windows) ... not for any particular reason, but the community supporting Ansible just sort of converged on that language as a DeFacto standard.

Now, as an "IBM Champion" I need to find ways to contribute to the greater good. And while I've been working on some other things (waiting to have them edited before I publish, which will be after our National Sales Meeting next week), I really wanted to fill a gap that I've seen in the Ansible collections for IBM.  IBM has great Ansible collections, many of them included in the Ansible Certified Collections1. But there was a very noticeable gap for me, and that was in the area of one of the platforms that I know best, IBM DS8000 family. 

Because of this gap, I actually decided over the past couple of weeks that I was going to start finding my way around learning Python (which I had wanted to do but never really found the time) and creating some modules for the DS8000. My plan had been to build a python module to generate an access token. Then I would have that feed into different python modules for everything that you could possibly do with the DS8000 API.

Today I had finally finished up a couple of parts (Since this doesn't replace my regular job, I was finding time where I could). Then a few minutes ago I was looking for some details on Python libraries and my search happened to pull up what my old colleague, @Randy Blea has been working on (his blog post is here: ... Apparently, he had the same thoughts that I did and published the full collection to Ansible Galaxy 2 days ago.

Now, as with anything, development work in these things is ongoing and maybe I can find a way to add to this open-source collection as a Contributor. But I think just as important is communicating the value of Ansible in a typical DS8000 environment. 

Over the next months, one of the things that I'm going to try to do is demonstrate some simple playbooks to demonstrate how easy it is to configure these resources with Ansible, and I hope to help answer questions that would help alleviate any concerns in the Mainframe (but also Power AIX/IBM i, even Windows) communities about how it works and how it can help the environment work more smoothly.

To that end, I have a request of you (yes, you the carbon-base life form interacting with this blog post).

What's a regular task that you do today that involves either the DS8k on its own, or that involves the DS8k and host environments? Something that you have to do on a regular basis. Something that users are frequently requesting from you.

I'll work to put together some playbooks and explain how it all fits together.

Just to clarify the concept of a "Certified Collection" -- Ansible modules and plugins are organized into "Collections". Historically they've been uploaded to Ansible Galaxy and maintained there by whomever is responsible. In many cases this is a vendor, though many individuals contribute as well.
However, if a problem were to occur, they would be the ones who would support the issue. Depending on how reachable they are, this could be great support or slow support. But with Certified Collections, Red Hat has determined that they can offer the necessary support to their Ansible Automation Platform customers. If a user has an issue, for example, with the zOS modules for CICS, Red Hat will actually fully support that and contact the IBM developers as needed.

Ansible is a registered trademark of Red Hat, Inc. in the United States and other countries.

1 comment



Mon April 04, 2022 10:15 AM

This is great!   Great blog and great to hear from you, Ian!  I'd love to hear what "use cases" may come from this blog.  We're excited to get the DS8000 more formally into Ansible, but there's a long way to go to get it where it needs to be.