IBM i Receives Package Manager Support

Analysis of News Events
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

With Red Hat Package Manager (RPM), IBM aligns itself with the open-source community.

From what I can tell, this story has not been covered anywhere, and that really surprises me. This is arguably one of the most important updates to IBM i in the history of the operating system. Not since the advent of PASE has there been an enhancement with the potential that this has. Now that's a tall order, I know.

How's that?

For starters, IBM i has historically had its software loaded by way of a licensed program installation (RSTLICPGM) and then updated by way of a PTF update (LODPTF/APYPTF). While there have been some exceptions to that rule over the years - for instance, loading WebSphere Application Server by way of Installation Manager (another non-RSTLICPGM install) - traditional software management has not really evolved until now.

A package manager - in this case, Red Hat Package Manager (RPM) - gives the IBM i admin the ability to install software via a method that is well-known in the open-source community.

From a future-planning perspective, I see a lot of potential. I see the ability to bring new software to IBM i (and then manage it) where there really wasn't an easy path to do that before. Maybe it's pie in the sky, but I foresee the ability to move some Linux workloads to IBM i. I see potential for software consolidation from X86-64 servers.

From a skill-set perspective, the more open IBM i can be, the greater the chances you can easily find people to manage it. It's just one more aspect of the system that's familiar to the open-source community. With familiarity comes confidence. With confidence, you keep and grow your customer base.

Of course, it's a new way to do things. And that may make people a little wary. If you're a meat and potatoes RPG shop that has no interest in open source, little will change for you. But if you're building applications with Node.js or Python, then you should be aware that RPM support will give you enhanced and, more importantly, more appropriate capabilities for managing those features.

I sat down with Jesse Gorzinski, Business Architect of Open Source Technologies on IBM i, and had a quick chat about the new RPM support.

Steve Pitcher: So, Jesse, what exactly have you folks been up to with the package manager?

Jesse Gorzinski: I want to be explicitly clear about what we've really done: We've better aligned ourselves with the greater open-source community. That has numerous benefits. For the sake of brevity, I'll summarize the top three.

First off, we can deliver more technology. The "RPM pile," as I call it, already has many more open-source packages than the 5733-OPS product, and we've done so with less investment. My development team has made great progress in terms of build automation, test, and delivery of RPMs. The IBM i PTF technology, while tried and true for our platform, simply was not built for open source. The RPM environment was built for open source.

Second, it simplifies the installation and management of open-source packages for the IBM i admin. While PTFs and PTF groups could do the job, it can't compare with what our RPM-based package manager can do. With a single command, an administrator can check for updates, see what new OSS is available, install new software, or even update their entire open-source stack! There's no need to install a licensed program like 5733-OPS or 5733-SC1. Just a few minutes and a few commands can do everything you need! Yes, this adds another necessary skill for admins, but I'm confident the net simplicity makes up for the learning curve.

The third reason is perhaps the most important. We're further enabling the IBM i open-source community. With a PTF-only ecosystem, IBM was the sole deliverer. After all, few people outside of IBM know how to build a PTF! With RPMs, we don't have to be the only player. We are using the same build methods as many flavors of Linux. In the future, I expect to see open source being built, packaged, and distributed by other parties, like IBM i clients, hobbyists, partners, or software vendors. If someone is interested in bringing new software to the platform, it's now easy to install the compilers and surrounding toolchain. Anyone with interest and motivation can now contribute. This will really drive growth of open source on IBM i!

SP: When you say there's no need to install OPS or SC1, would we need a base option or option 7? Or is there simply no need for OPS at all moving forward? Also, will we end up seeing Java go down that path to be installed/patched via RPM rather than via licensed programs and PTFs? And if that's the case, would there be value in RPMing more traditional applications? Let's say...DG1 (it's Apache after all). Or even something like BRMS. Not sure if that could even be done, but if there's a line in the sand, I want to make it more visible.

JG: Today and moving forward, there is no need for the OPS installed product at all. It's unlikely that Java will also go down this path, as RPMs are optimized for UNIX-derived environments (PASE). Because of its history, Java exists in PASE, ILE, and licensed internal code, so it's not as great a fit. Regardless, RPMs can do ILE installs in a roundabout way. There could definitely be value in shipping existing stuff as an RPM. Much of that realm is not yet explored, though.

SP: I'll press you on DG1. Same thing? Since you mentioned education, how does the average admin get up to date on this? Where can they get started, assuming they're RPM-friendly? Assuming not, what can we do to help them on their way?

JG: Just to be 100 percent clear, for obvious reasons IBM is not going to stop shipping DG1 in favor of RPMs. A hypothetical future could involve a second Apache option, built from community source, from some community participant. As I mentioned, anybody can potentially build this stuff because getting compilers set up is so easy, so there's nothing stopping people.

A great place for an admin to start would be our "Open Source RPMs" documentation linked off the Open Source Technologies developerWorks page. We have commands documented to install the open-source environment, as well as some simple examples of how to install things. The package manager we've delivered is called "yum," which is still in use by several Red Hat Linux distributions. So, also be aware that the web is rich with documentation on the tool. A few commands will be learned quickly, though, and might be all that's needed. For instance, running yum install nodejs will install Node.js version 8. A yum upgrade will upgrade all the packages, etc.

SP: I'd expect admins to learn the new tooling rather than promote developers to the traditional admin role of managing installed software. When I first heard about RPMs on the platform, I was immediately thinking about a sort of "authority scope creep." The key is to get admins to expand their skill set. Not that expanding developer rights is a bad thing. It just needs to be discussed.

Even for us...we load OPS as part of every 7.2 and 7.3 upgrade we do. We have to at least think about loading base RPM technology capabilities instead. What I do like about this is that the Linux-friendly techs see this on IBM i and have something immediately familiar. It potentially grows the platform audience immediately.

JG: Exactly. In that regard, we're not changing the narrative here. The separation of duties exists in the same manner as before. While the delivery of more open source benefits everyone, the RPMs and package manager can make the admin's job easy. And, as you say, being "familiar" to Linux folks (whether programmers or admins) has its perks.

SP: So while not being Linux, what would the package manager support do for the average person with Linux workloads? Let's say someone had a Linux server for a CRM function or a firewall. Could they theoretically be able to yum install it and move that workload with minimal trouble?

JG: As in, "move that workload to an IBM i"? If the packages were available on i, then it would make things easier. One could get the same packages yum installed on i, then just work to migrate the rest of the application (config/data/etc.). Of course, as the IBM i OSS ecosystem grows, we'll be seeing more and more things for which that's possible.

The move to RPMs is much more significant than just a new delivery/install mechanism. It's going to enable open source to really take off on this platform. I've never been so excited by what the future brings for IBM i!

BLOG COMMENTS POWERED BY DISQUS