SUSE Public Cloud Image Life-cycle

Updated Sep-26-2024: Life cycle changes for PAYG due to simplified LTSS support

Updated Oct-30-2019:  Added new section addressing instances

It has been a while since we published the original image life-cycle guidelines SUSE Image Life Cycle for Public Cloud Deployments. Much has been learned since, technology has progressed, and the life-cycle of products has changed. Therefore, it is time to refresh things, update our guidance, and clarify items that have led to questions over the years. This new document serves as the guideline going forward starting February 15th, 2019 and supersedes the original guideline. Any images with a date stamp later than v20190215 fall under the new guideline. The same basic principal as in the original guideline applies, the image life-cycle is aligned with the product life-cycle of the product in the image. Meaning a SLES image generally aligns with the SUSE Linux Enterprise Server life-cycle and a SUSE Manager image generally aligns with the SUSE Manager life-cycle.

The life-cycle of an image has 4 status indicators, active, inactive, deprecated, and deleted. Every framework has different ways of dealing with image life-cycles and the information about state is not necessarily readily available in any given cloud framework. For this reason we have the pint tool and it provides the truth about the state of an image.

The pint tool also provides a library that can be integrated into Python code and thus it is easy to always find the latest image to launch new instances in an automated fashion. There is also an example about how to use the Public cloud INformation Tracker REST API with lambda in a cloud formation template for EC2 to help you with automation in case you use CFN.

In addition to the four states for an image we have the distinction between on-demand and BYOS images , between products such as SUSE Linux Enterprise Server and SUSE Linux Enterprise Server For SAP Applications, and between image refreshes and update availability. Unfortunately the whole topic is not straight forward, but hopefully by the time you get to the end of this things will make sense.

Let’s begin with some general definitions that then get refined based on additional criteria.

• active images
  • active images are on a 3 months rolling refresh cycle (more on this in a minute)
• inactive images
  • inactive images will only get refreshed for critical security updates, think shellshock, heartbleed, or the more recent Specter and Meltdown issues.
• deprecated images
  • deprecated images do not get refreshed. Images in the deprecated state have entered the last 6 months of their life-cycle and are subject to removal at the end of the 6 months period

In general you should always use active images to launch instances for new deployments.

Before we refine the general definitions above let’s define the idea of a 3 months rolling refresh cycle. This means that images get refreshed every 3 months from the last refresh, but the last refresh is not necessarily 3 months after the previous refresh. This definition certainly asks for an explanation by example.

If we assume we refresh images on March 1st and there is no security incident that requires an image refresh then images will get refreshed on June 1st, 3 months after the last refresh.

That part is pretty simple, right?

Now let’s assume we release an image refresh on May 1st and on June 15th there is a major security issue that causes us to refresh our images. That implies that the 3 months clock is reset to 0 on June 15th and the next image refresh would be on September 15 if no other security issue occurs that triggers an image refresh.

Put together that makes up the 3 month rolling image refresh cycle. Our images continue to be date coded with a date string in the format “vYYYYMMDD” in the image name to make it easy to always find the latest image.

Given that an image has a state and there are multiple states we must also define the state transitions. A state transition is always associated with some event either in the refresh cycle or in the product life-cycle.

The product life-cycle for SLES defines transitions for Service Pack releases, new major releases and a Long Term Servicepack Support period. As of September 26, 2024 it is possible to add LTSS to PAYG instances without having to use an additional SUSE Product.  The beginning of the LTSS period remains significant for on-demand and BYOS images, more on this below.

The product life-cycle for SLES For SAP defines an Enhanced Service Pack Overlap Support (ESPOS) and an LTSS period.

Both LTSS and ESPOS are connected to certain image states, and we’ll make that connection in a minute and both of these time periods are related to Service Pack releases or EOL events. Time periods are published on the life-cycle page.

And with no further ado let’s dive into the details for SLES and SLES For SAP.

On-Demand images

Refresh cycle:
On-demand images follow the 3 months rolling refresh cycle explained above. In addition to critical security issues we consider bugs that effect proper functioning of an instance as it relates to framework functionality and other issues such as local privilege escalation on a case by case basis as refresh events.

Update availability:
On-demand instances automatically connect to the SUSE operated region associated update infrastructure. Updates are available for images in active, inactive, and deprecated states for SLES and SLES For SAP. No new updates become available once an image reaches the end of the deprecation period. For a distribution in LTSS additional repositories must be added to receive updates.

Image state transitions:
When an image is refreshed during the regular 3 months rolling refresh cycle the image that is being replaced immediately enters the deprecated state.

At Service Pack transition points the behavior between SLES and SLES For SAP differs. While the state transition for both is from active to  inactive the behavior with respect to receiving  updates is different. 6 months after the SP transition SLES For SAP enters the ESPOS period, except for the final SP in which case SLES For SAP enters the LTSS period, and SLES enters the LTSS period. During the ESPOS period updates for SLES For SAP continue to be available in the already configured repositories. Once a distribution enters the LTSS period updates are only available through the LTSS repositories which need to be added explicitly to a system and require a registration code. Images transition from inactive to deprecated 6 months prior to the End Of Life (EOL) date.

For the final SP the behavior for SLES and SLES For SAP is the same, images enter the deprecated state 6 months prior to EOL.

Image availability:
On-demand images will be available for launch until the end of the LTSS period.

BYOS images

Refresh cycle:
BYOS images follow the 3 month rolling refresh cycle explained above. Only critical security issues or instance boot issues are considered as out of band refresh events.

Update availability:
BYOS instances need to get registered to the SUSE Customer Center or the SUSE Operated update infrastructure, a Repository Mirroring Tool server or Subscription Management Tool server, or be managed with SUSE Manager in order to receive updates. The availability of updates and repositories is governed by your product selection just like it is in the data center. Any new deployments of your own management and patch solution should be completed using SUSE Manager or RMT.

Image state transitions:
When an image is refreshed during the regular 3 months rolling refresh cycle the image that is being replaced immediately enters the deprecated state.

At Service Pack transition points the behavior between SLES and SLES For SAP is identical and images being replaced by the next service pack enter the inactive state. The inactive state is maintained until 6 months prior to the end of LTSS or ESPOS as applicable at which point the image enters the deprecated state.

Image availability:
BYOS images will be available for launch until the end of LTSS or ESPOS support (deprecated state)

And that’s pretty much it. Over the next few weeks we will refresh images for which the new life cycle policy is to apply to ensure they have a date stamp for a date later than February 15th, 2019. Any images that you maybe interested in and that do not get refreshed by March 31st, 2019, will continue to be governed by the old life-cycle policy.

Update 2019-07-02:

As we were working with the new guidelines an omission surfaced and this is being addressed here.

Feature Enablement

This applies to both on-demand and BYOS images. Feature enablement in most cases requires work in the kernel. This may be the update of code for a specific driver, the inclusion of a new driver or other changes that improve performance, enable new instance types etc. Feature enablement will only take place for images in the active state. Should the enablement work cross the release of a service pack or distribution it will be decided on a case by case basis if the work should be carried in both releases or if it should be carried only in the new release. The instance support matrix provides updated information at release transition points to clarify which instance types are supported by each release.

End Update 2019-07-02

Update 2021-08-16:

• Created a link to the instance support matrix in the comment from 2019-07-02 and adjusted the wording accordingly.

Since the blog was written and the life-cycle has taken effect a new use case has emerged which requires an addition to the life-cycle guidelines. SUSE may, as the need arises, build special images from a given product. These images are considered flavors and are generally created to address a specific use case/need. To better serve the needs special flavor builds from products may follow different refresh cycles.

End Update 2021-08-16

How does this effect running instances?

The short answer is that the image life-cycle has NO effect on running instances. A running instance basically has a private copy of an image as it’s backing store and this private copy remains unchanged as the image from which the instance originated moves through the life-cycle and eventually gets deleted. That said, running instances still need attention. It is important to keep your running instances up to date by installing updated packages, zypper up is the simple and straight forward way to do this, and to migrate your instances across Service Packs, zypper migration will handle this process, in order to ensure you keep your running instances in a supported and supportable state. In this regard a running instance is no different than a bare metal system you would run in your own data center. The service pack transition period for SUSE Linux Enterprise Server is 6 months and for SUSE Linux Enterprise Server For SAP Applications the transition period is 4.5 years. Specific dates can be obtained from the general SUSE life-cycle page. The transition period is th etime period during which a system needs to be migrated to be considered in a supported state. For BYOS instances the transition period can be extended via LTSS (Long Term Service Pack Support) and for on-demand instances LTSS can be obtained via SUSE Manager. Needless to say new instances should always be started from the latest image which can be found using pint.

To close, a quick summary of the highlights:

• As of February 15, 2019 images will follow a 3 months rolling refresh cycle.
• Images in the deprecated state do not get refreshed.
• Images in the inactive state only get refreshed for critical security issues.
• The deprecation period starts 6 months prior to the end of general support for on-demand images.
• The deprecation period starts 6 months prior to the end of life for BYOS images.
• Images will get removed at the end of the deprecation period.
• Image status can be obtained using the pint tool.
• Running instances are not effected by the image life-cycle, however instance need to be maintained w.r.t. update installation and service pack migration