Always Verify gplbin

The file gplbin, also known as the “portability layer”, is built from the source file gpfs.gpl and is the interface of IBM Spectrum Scale with the Linux kernel. It allows IBM Spectrum Scale to run on a wide range of kernel versions without having to recompile the entire product. You need to update gplbin under two circumstances:

1. The Linux kernel version has changed; or
2. The IBM Spectrum Scale code level has changed. Note that this applies to any IBM Spectrum Scale change, whether Version, Release, Mod or even Fix Pack (PTF)

See the IBM Spectrum Scale Knowledge Center for instructions on recompiling and distributing the gplbin file.

Versioning Process in IBM

IBM Spectrum Scale uses the common numbering format of IBM software products (see https://www-01.ibm.com/support/docview.wss?uid=swg27008656), which specifies the Version, Release, Mod Pack, and Fix Pack, or “v.r.m.f”. (Fix Packs are also known as PTFs.)

IBM’s maintenance lifecycle policy is based on the Version-plus-Release level (e.g. 4.2, 5.0). Each IBM Spectrum Scale Release is supported for a minimum of 3 years. IBM Spectrum Scale delivers Mod Packs to the latest supported Version-plus-Release. Versions, Releases, and Mod Packs all add product functionality. We provide Fix Packs only for the latest Mod pack only of each still-supported Release,. These Fix Packs are provided usually six to eight weeks apart. Once a new Mod pack is released, there are no further Fix Packs for older Mod packs in that Release. Fix Packs do not add product functionality.

Normally, we try not to have more than two supported Releases active at a time. Hence we aim to create a new Version or Release only when a previous one is coming to its End of Support (EOS). Once a Release reaches EOS, no further Mod Packs or Fix Packs will normally be released for it.

Versioning Process at Red Hat

Red Hat Enterprise Linux (RHEL) uses a numbering scheme based on Major and Minor releases, e.g. 7.6 or 8.0.The details are quite different and more complicated compared to IBM’s process. Major releases are expected to be supported for a long time, perhaps a decade¹. Consequently, it is typical that more than one Major release is supported and maintained at any given time. During its life, a Major release will have a number of Minor releases that add new functionality. The latest Minor release of each Major release receives frequent updates known as “Errata”. These are divided into Bug Fix Errata (also known as RHBA), Security Errata (RHSA) and small feature enhancements (Enhancement Advisories, or RHEAs). Each active Minor release has its own Errata stream.

¹The description here applies to current Red Hat releases. Earlier releases may not have followed the same practices.

Standard support is divided into a number of phases, including Full Support and Maintenance Support, which ends with retirement, or end of life (EOL) of the Major version. At that point, no further Errata or Minor releases will normally be provided for that Major release.

So approximately, a RHEL Major release level is similar to an IBM Version-plus-Release level; a RHEL Minor release level is similar to an IBM Mod pack; and RHEL Errata corresponds to IBM’s Fix Packs.

However, there is more to the Red Hat maintenance story. Minor releases are typically separated by some months, and Red Hat recognizes that not every site can adopt every Minor release as it comes out. For example, many RHEL users adopt a policy to revalidate applications for compatibility at each Minor release, thus making moving over to a new Minor level, a substantial effort.

Therefore, Red Hat offers an optional service called Extended Update Support (EUS). EUS provides subscribers with selected “urgent priority” RHBAs and “critical impact” RHSAs for their chosen Minor release without requiring an upgrade to the next Minor or Major release. This allows a RHEL user to remain on a chosen Minor release for an extended period of up to [AC1] 24 months after a new Minor release becomes available, and then skip several Minor levels at their next upgrade. Depending on release timing, several Minor releases can be in EUS simultaneously. In other words, RHEL typically has many more active Errata streams than IBM Spectrum Scale’s PTF streams. For more information, see https://access.redhat.com/articles/rhel-eus.

Note that EUS is not offered for every Minor release. In particular, once a Major release leaves the Full Support phase and enters the Maintenance Support phase, EUS is not provided for subsequent Minor releases. Only the most recent Minor release receives Errata. This means that sites that want to continue to receive Errata but are not ready to move to a new Major release typically adopts one of two strategies:

• Remain on a Minor release from the Full Support phase as long as EUS remains available for that release; or
• Upgrade to each Minor release in the Maintenance Support phase as it is released

For RHEL 6, the last release to receive EUS was 6.7, and its Errata stream ended in December 2018. Since that point, the only way to continue to receive Errata for RHEL 6 has been to stay on the most recent Minor release. The most recent at time of writing (and expected to be the last) is 6.10, with EOL planned for November 30, 2020. After that, customers who want Errata will need to move to a later Major release.

RHEL 7 is still in the Full Support phase, and several of its Minor releases have EUS available. Full Support is expected to end towards the end of 2020, at which point the same two options described above will be available to continue to receive Errata on RHEL 7. Alternatively, you can also upgrade to RHEL 8.

RHEL 8 was released on May 7^th, 2019. Red Hat has indicated that it does not intend to provide EUS for release 8.0. The first Minor release to have EUS offered is 8.1. Starting from 8.2, only alternate (even-numbered) RHEL 8 Minor releases will have EUS.

Versioning Process at SUSE

SUSE provides a model similar to that of Red Hat for its SUSE Linux Enterprise Server, or SLES. Each currently supported Release of SLES has a 10-year general support life², and the full lifecycle policy can be found at https://www.suse.com/support/policy/. Currently SLES 12 and SLES 15 are supported (SLES 11 general supported ended March 31, 2019, and SUSE skipped release numbers 13 and 14 for marketing reasons).

²Starting with SLES 11, SUSE typically provides a 13-year lifecycle including 10 years of General Support plus optional Extended Support for up to an additional three years. Earlier releases had shorter lifecycles.

Every twelve to eighteen months, all supported releases receive periodic Service Packs (SPs corresponding to IBM Spectrum Scale Mod Packs or RHEL Minor releases). Normally, each Service Pack remains supported for six months after its successor is released, providing a window for upgrade planning.

In between Service Packs, SUSE publishes maintenance and security patches for supported Service Packs, equivalent to Scale’s PTFs and RHEL’s Errata.

Like Red Hat, SUSE also accommodates customers who do not want to adopt every Service Pack, or who want to remain on a specific Service Pack beyond the six-month upgrade window. For this purpose, SUSE offers the optional Long-Term Service Pack Support (LTSPS). This allows a customer to purchase one, two, or three years of additional support after the end of support life of a Service Pack. During the Long-Term support period, SUSE continues to provide technical support, security patches for critical vulnerabilities, and maintenance patches for non-security issues that it considers critical. When LTSPS for a given Service Pack comes to an end, the customer can upgrade to a supported Service Pack, skipping intermediate Service Packs if they choose.

Versioning Process at Canonical

Canonical takes a different approach with Ubuntu, compared to SLES and RHEL. It emphasizes on  stability over currency for enterprise releases and focuses on two-yearly Long-Term Support (LTS) releases.

In principle, as far as possible, Ubuntu follows a six-month release calendar. Each release is named for the year and month of release: For example, version 18.04 was the release in April of 2018. An Ubuntu release is comparable in scope to a Major or Minor release of RHEL and a Release or Service Pack in SLES. Customers should expect to revalidate applications when taking a new release. Each Ubuntu release is supported for nine months, providing a three month overlap for customers to migrate from one release to the next if they want to stay current with each new release.

In practice, Ubuntu customers are typically not taking these so-called “interim: releases that frequently. Instead, most of them take only LTS releases, as many as 95% of Ubuntu installations, by Canonical’s own estimates. For this reason, IBM Spectrum Scale only validates against Ubuntu LTS releases, not interim releases. Every fourth Ubuntu release is an LTS release, and is supported for five year³. (Consequently, as many as three LTS releases might be supported by Canonical at one time.) For more information, see https://ubuntu.com/about/release-cycle.

³Extended Security Maintenance is also available for purchase for LTS versions, potentially extending the support lifetime up to a total of 10 years for the most recent releases.

During the support lifetime of an LTS release, updates are delivered approximately every six months. These updates are reflected in the third digit of the version number, e.g. 18.04.1 and compared in scope to a RHEL Minor release or a SLES Service Pack. Reflecting the inherent conservatism of LTS releases, these updates typically contain content that was previously released in an interim release and therefore has some real-world exposure.

Like the other vendors, Canonical also provides frequent security and fix patch streams for supported versions.

Putting it all together: The Support Matrix

With so many versions and releases of both IBM Spectrum Scale and Linux supported at one time, the possible combinations are inevitably going to be complicated. We recognize that many of our customers want to take advantage of the EUS streams of RHEL or the LTSPS of SUSE so that they can avoid frequent significant OS upgrades as well as revalidation or even upgrades to applications – including IBM Spectrum Scale. We also recognize that upgrading IBM Spectrum Scale is an undertaking that typically requires planning, including potentially revalidating the applications that in turn run on top of IBM Spectrum Scale.

At the highest level, our matrix determines which IBM Spectrum Scale Versions and Releases are supported with each RHEL Major release and each SLES Release. For example, IBM Spectrum Scale 5.0 is supported with RHEL 7 and RHEL 8, as well as SLES 12 and 15. Meanwhile, the older 4.2 supports both RHEL 7 and RHEL 6 and both SLES 12 and SLES 11. For more information, see Q2.2 in IBM Spectrum Scale FAQ in the IBM Knowledge Center.

In order to keep the test matrix sustainable, we assume that an Enterprise concerned with remaining current on support and Errata or patches will keep both IBM Spectrum Scale and the Linux distribution up to date.

Consequently, we adhere to the following guidelines :

• For RHEL: When a new IBM Spectrum Scale Version or Release comes out, we plan to support it on the actively supported RHEL Minor releases with Errata streams; i.e. the ones with active EUS plus the latest Minor release of each active Major release. We will not usually go back to validate and test on RHEL releases that are no longer supported by Red Hat.
• When a new RHEL Minor release comes out, we plan to support it with the next possible IBM Spectrum Scale deliverable for each IBM Spectrum Scale Version supported on that Major release. In some cases that is the next Mod pack. In other situations, it will be a Fix Pack, and sometimes testing will prove that the current version is supported without modification. For example, once RHEL 7.6 was released, we supported it starting it with IBM Spectrum Scale 5.0.2.2. However, we don’t add support for out-of-supported versions of IBM Spectrum Scale, for example IBM Spectrum Scale 5.0.1 on RHEL 7.6.
• For SUSE: When a new IBM Spectrum Scale Version or Release comes out, we plan to support it on the actively supported SLES Service Packs with patch streams; i.e. the ones with available LTSPS or General Support. We will not usually go back to validate and test on Service Packs or Releases that are no longer supported by SUSE.
• When a new SUSE Release or Service Pack comes out, we plan to support it with the next possible deliverable for each IBM Spectrum Scale Version supported on that Major release. In some cases that will be the next Mod pack, while in some it will be a Fix Pack. Sometimes testing will be done to prove that the current version is supported without modification. For example, when SUSE 12 SP4 released, we supported it starting it with IBM Spectrum Scale 5.0.2.3. However, we will not support IBM Spectrum Scale versions that are no longer supported like 5.0.1 on SUSE 12 SP4.
• For Ubuntu: When a new IBM Spectrum Scale Version or Release comes out, we plan to support it on the actively supported Ubuntu LTS releases at the most recent third-digit version level. We will usually not go back to validate and test on releases that are no longer supported by Canonical.
• When a new third-digit version to an LTS is released, we plan to support it with the next possible deliverable for each IBM Spectrum Scale Version supported with that LTS release. In some cases that will be the next Mod pack, other times it will be a Fix Pack. Sometimes testing will prove that the current version is supported without modification. However, we won’t go back and support no longer supported versions of IBM Spectrum Scale such as 5.0.1 on the new version.
• For IBM Spectrum Scale: When each IBM Spectrum Scale Mod pack is released, the same principles will apply. Note that this means that as older RHEL Minor releases “age out” of EUS, later Mod packs of IBM Spectrum Scale might not support them, even if earlier Mod packs of the same Release did. For example, RHEL 7.4 is approaching the end of EUS later in 2019. Once that happens, we plan to stop testing subsequent Mod packs of IBM Spectrum Scale with that release. Similarly, when SUSE Service Packs fall out of LTSPS, we will cease to validate IBM Spectrum Scale Mod packs with that Service Pack. And in the same way, once an Ubuntu LTS release falls out of support, we will no longer validate IBM Spectrum Scale Mod packs with that release. In general, customers who choose to remain on an unsupported release of their Linux distribution will also need to remain on an unsupported release of IBM Spectrum Scale.

This provides a wide degree of latitude for choosing your rate of update for both IBM Spectrum Scale and Linux while keeping both on supported versions.

One final and important thing to note is that the above guidelines are not absolute. Sometimes, following these guidelines would result in an infeasibly short support window for a particular combination of IBM Spectrum Scale release and the Linux distribution release. For example, if a Minor release of RHEL is supported by Red Hat under EUS at the time a IBM Spectrum Scale Release or Mod pack is made available, but is scheduled to fall off EUS very shortly afterwards, we might choose not to support it. Also, if a SUSE Service Pack comes out closely before a IBM Spectrum Scale release date, it might not be possible to test it in time for our release, so support will be deferred to a later Fix pack. Moreover, if an IBM Spectrum Scale release approaches its End of Support today, we may choose not to validate it against new releases of the respective distributions if that would result in a short support lifetime.

Finally, from time to time we make strategic decisions to exclude certain combinations of old and new. For example IBM Spectrum Scale V5 is not supported with RHEL 6 or SLES 11, even though both remain supported by their respective distributors.

To conclude, it is recommended that you always check the matrix and do not make assumptions based on relative release dates alone.