Long Term Service Pack Support for PAYG Instances Simplified

Long Term Service Pack Support (LTSS) is an add-on product for SUSE Linux Enterprise distributions that affords the extension of support for Service Packs (SPs) for up to 3 years. Until now getting an add-on product such as LTSS and applying it to Pay As You Go (PAYG) instances was only possible with some business trickery and by using SUSE Manager. This rather cumbersome process has been replaced by a more streamlined process for LTSS. Other extensions still need to proceed with the route through SUSE Manager.

With the SUSE Linux Enterprise 12 code base reaching the end of general support on October 31st, 2024, just a few weeks away, we have worked with our partners at AWS, Google, and Microsoft to provide a better process and make it easier to add LTSS repositories for PAYG instances.

While there is limited support of an add-on model in GCE such support is not available in Azure or EC2. Therefore we opted for a unified process that will work in all CSPs (Cloud Service Providers). Direct self service transactions through the respective marketplaces for LTSS is not possible. But you can still transact through the CSP if you so desire via a Private Offer.

How It Works

Reach out to cloudsales@suse.com to work out the commercial details about getting LTSS. This can then be transacted through the CSP via private offer, as mentioned, or via direct transaction with SUSE. You will receive a subscription and access to SCC, the SUSE Customer Center. With your subscription you can activate a registration code for LTSS for your specific Service Pack (SP). LTSS subscriptions are product and SP specific, meaning you can only use an LTSS subscription for, for example SLES 15 SP4, with SLES 15 SP4, you cannot use that registration code and register a 15 SP3 instance to get access to the 15 SP3 LTSS repositories.

With your registration code at hand you need to prepare your instance; this is simple by running

zypper up cloud-regionsrv-client

or zypper up to update everything on your instance. This will deliver the cloud-regionsrv-client package with version 10.3.4 or greater to your instance. Version 10.3.4 is the minimum required version in order to get LTSS working in your instance. Once you have this version of the cloud-regionsrv-client package you simply run

registercloudguset -r $YOUR_LTSS_REGISTRATION_CODE

PAYG instances are already registered and your instance stays connected to the SUSE operated update infrastructure. The use of LTSS for your instance will be reported back to SCC such that you can see how many entitlements of your subscription for LTSS are in use in the SCC Dashboard.

Yes, this also means that if you already have an LTSS subscription that you are using in your data center you can deregister a system in your data center and move that use of your LTSS subscription to a PAYG instance in the Cloud. The was previously only possible for BYOS instances or via SUSE Manager.

Once you run the above registercloudguest command, you will see the following messages:

Running LTSS registration...this takes a little longer
LTSS registration succeeded

At this point you will have access to the LTSS repositories, meaning you continue to receive updated packages for your instance.

On the support front everything stays the same, meaning you will continue to reach out to your CSP support contact and SUSE will back up our partners if there is anything related to the distribution. From this you can surmise that this streamlining in adding LTSS to your instance is a collaborative effort between SUSE and our Partners. Without the agreement of AWS, Google and Microsoft to continue to support instances with a distribution in LTSS this would not be possible.

What Else

Once your system has LTSS setup you also get access to the LTSS container registries. While the rollout of registry support had a few bumps we have sorted those out and you can access the LTSS containers that are part of your LTSS subscription. When you executed the LTSS registration command given above the code also configured the registry setup on your system to point to the registry that is part of the update infrastructure. Before you can use the container registry you will need to log out of your instance and log back in. The registry setup requires that we modify the shell environment and in order for this modification to take effect you need to restart, i.e. log out and log back in, your sessions. Once you have completed this process you can use podman.

zypper in podman

Once you have podman installed you can search for ltss containers as follows:

podman search ltss

Note that ltss containers do not have a latest tag as such a simple

podman pull suse/ltss/sle15.4/bci-base

will not work. If you run the above command you will get the choice between the 2 configured search registries, the CSP specific registry that is part of the update infrastructure and the SUSE registry. You will need to select the CSP specific registry, i.e. registry-*.susecloud.net since ltss containers are part of an access path that requires authentication and the PAYG system can only authenticate to the registry that is part of the update infrastructure.

But back to pulling an ltss container, after this little excursion. The

podman search ltss

returned results about the available ltss containers including the registry path. You want to use that result to list the tags, if you are on EC2 this looks like this:

podman search –list-tags registry-ec2.susecloud.net/suse/ltss/sle15.4/sle15

and then pull the container with

podman pull suse/ltss/sle15.4/sle15:15.4.3.30

for example. In Google the registry is registry-gce.susecloud.net and in Azure it is registry-azure.susecloud.net. For more information about SUSE containers please refer to the Container documentation. Also note the use of the explicit tag is for ltss container images. For container images of the current distribution there is a latest tag and as such, for example

podman pull bci/bci-base

will just work and you do not need to know any more details. That container will be delivered from the SUSE registry as it is not on an authenticated path.

We still have some caveats

With the SUSE Linux Enterprise 12 code base reaching the end of general support on October 31st, 2024 we were under considerable time pressure to make LTSS access for PAYG simple in a hurry. As such there are a some warts that we ran across at the end of the test cycle but didn’t get to address just yet. These will be fixed in the not too distant future. None of the warts lie within what is considered the main use case, but for awareness here they are:

1.) Round trip LTSS is not working

In this use case LTSS is registered with

registercloudguest -r $YOUR_LTSS_REGISTRATION_CODE

and then removed with

SUSEConnect -d -p SLES-LTSS/$VERSION/$ARCH

where $VERSION could be 15.4 for example if registered on a 15 SP4 system. Trying to re-add LTSS with

registercloudguest -r $YOUR_LTSS_REGISTRATION_CODE

will fail. One will have to start from scratch, i.e. use the following sequence of commands:

SUSEConnect -d -p SLES-LTSS/$VERSION/$ARCH
registercloudguest –clean
registercloudguest
registercloudguest -r $YOUR_LTSS_REGISTRATION_CODE

2.) Registry re-authentication

Credentials for access to the update servers get re-verified on a periodic basis upon access request. Whenever repositories get accessed via zypper this process happens automatically. It is not possible to build such automation for the supported container tools, docker and podman. As such it may happen that a full verification process for registry access is required. For this case the

cloudguestregistryauth

command was created. It can be executed by any user on the system and will handle the necessary full instance verification cycle. One knows that it is time to run the cloudguestregistryauth when registry access is denied with a permission error.

When a system has LTSS setup this command does not work as it should. In order to facilitate the re-verification process of the instance one has to be root and run

zypper ref --force

Which brings me to the last caveat.

3.) zypper ref –force may produce errors

With LTSS registered and after no updates have happened for a while

zypper ref --force

may show spurious errors. Re-run the command (zypper ref –force) to clear those up.

Really nothing all too bad.

Things to keep in Mind for LTSS

Beside the temporary caveats listed above, and we will have those fixed by the end of 2024, there are some permanent topics to keep in mind when using images from distributions in LTSS.

1.) You should not start net new workloads

LTSS is intended to provide support for things that are already running and cannot yet move to a setup that is in general support. When starting new workloads you should always use an image that is in active state, i.e. an image with a SP in general support.

2.) Life-cycle changes for PAYG images

With the availability of adding LTSS to PAYG without requiering another product the reason to remove PAYG images at the end of the general support period has vanished. This means PAYG images will now follow the same life-cycle that BYOS images already have. When a new Service Pack (SP) becomes available the PAYG images of the previous SP move to the inactive state instead of the deprecated state. The inactive state is retained until 6 months before the end of LTSS at which point the images moves to the deprectaed state.

3.) New Instance Type Enablement

Generally there will not be any new instance type enablement for anything that is in LTSS, images in the inactive state. Instance types that become available after an image moves from active state to inactive state may work but no specific work will be done to enable new instance types.

With this, we hope that the streamlined process of adding LTSS to a PAYG instance meets your needs should you find yourself in a position where migration to a newer version of the distribution is not yet possible and the need for LTSS arises.