BYOS Instances And The SUSE Public Cloud Update Infrastructure

Way back when in 2015 I wrote about differences between BYOS and on-demand images in “On Demand, BYOS, say what? Why do I need it?” mentioning that on-demand images contain “special sauce” that register an on-demand instance automatically to the SUSE operated update infrastructure in AWS EC2, Azure, and GCE. Much has changed since then, and with a project that we completed at the end of 2021 the “special sauce” is no longer just for on-demand images.

The “special sauce” is the cloud-regionsrv-client project in GitHub that is part of the SUSE-Enceladus  organization. Changes applied on the server side in conjunction with changes that are included in the cloud-regionsrv-client package with version 9.3.0 and later make it possible to register BYOS instances to the SUSE update infrastructure in AWS EC2, Azure, and GCE.

For BYOS images with a datestamp later than 20220103, spare -chost- images, the cloud-regionsrv-client package will be installed by default to make registration more straight forward. Unlike for on-demand instances the registration is not automatic on instance startup. The reason for this is that your SUSE registration code is required for access to the update infrastructure. The -chost- images are optimized for container workloads and contain only a small set of extra packages outside of the bare minimum to make containers run.

If you are managing all your instances with SUSE Manager or if you are running your own RMT servers this change is probably not all that interesting to you. However, if you generally register your instances directly to the SUSE Customer Center (SCC) this change can make a significant difference in how fast you get updates onto your systems. Package updates are transferred to your system using the cloud framework backbone which provides better throughput than accessing the CDN over the Internet when an instance is registered to SCC.

How does it work?

The registercloudguest command gained new options, the –email and –regcode command line arguments can be used, these mirror the SUSEConnect arguments, to register a BYOS instance against the SUSE update infrastructure. When data for these options is received server side, the update server running in the framework, the update server will check with SCC that the product being requested for registration is associated with the given registration code. When this check passes the cloud based update server passes the repository information back to the client and the system will get update packages from the framework based update infrastructure instead of the CDN that is driven by SCC. When the client comes to visit for updates the framework based update server verifies that the registration has not expired before handing out updates. If the registration has expired an error will be reported. That’s it in a nutshell.

Because we create a link with SCC this implies that the system that is registered against the update infrastructure shows up in the SCC UI alongside any other systems registered against SCC. The system also, naturally, counts against the system count associated with the subscription.

Great, how is this used?

The pre-requisite is that you have cloud-regionsrv-client version 9.3.0 or later on your system. This version of the package has been released to the Public Cloud Module and can be installed using zypper. Systems that run in the Public Cloud should have the Public Cloud Module repositories set up.

In addition to the cloud-regionsrv-client package you will need some framework specific packages:

For AWS these are cloud-regionsrv-client-plugin-ec2, regionServiceClientConfigEC2, and regionServiceCertsEC2.

zypper in cloud-regionsrv-client cloud-regionsrv-client-plugin-ec2 regionServiceClientConfigEC2 regionServiceCertsEC2

will do the trick.

For Azure the additional packages are cloud-regionsrv-client-plugin-azure, regionServiceClientConfigAzure, regionServiceCertsAzure.

zypper in cloud-regionsrv-client cloud-regionsrv-client-plugin-azure regionServiceClientConfigAzure regionServiceCertsAzure

will do the trick.

For GCE the additional packages are cloud-regionsrv-client-plugin-gce, regionServiceClientConfigGCE, and regionServiceCertsGCE

zypper in cloud-regionsrv-client cloud-regionsrv-client-plugin-gce regionServiceClientConfigGCE regionServiceCertsGCE

will do the trick.

After these are installed you want to disconnect your instance from SCC using

registercloudguest –clean

SUSEConnect -d will no longer work.

Registering a system to the update infrastructure requires that the initial registration be completed with the registercloudguest command and not with SUSEConnect. Only after the initial registration is completed with registercloudguest will the instance be setup such that subsequent SUSEConnect commands will work against the update infrastructure rather than SCC.

The workflow to register against the update infrastrutcure is as follows:

registercloudguest –regcode $REGCODE

This will register the system using the given registration code to the SUSE update infrastructure and will inform SCC that the subscription has been used to register a BYOS instance in the Public Cloud. This will only register the base product and any recommended products. For instances created from images with a date stamp later than 20220103 this will also automatically set up the repositories for the Public Cloud Module. For instances created from images with a date stamp prior to 20220103 it is highly recommended that you at least also add the Public Cloud Module repositories. For example:

SUSEConnect -p sle-module-public-cloud/15.3/x86_64

will add the Public Cloud Module for SLES, SLES For SAP, and SLE HPC based on 15 SP3. In SLE 12 modules are service pack independent and as such the number is always “12”. For those familiar with registration against SCC this command line will look familiar. The triplet expected by SUSEConnect is the product followed by the distribution version followed by the architecture. Use

SUSEConnect –help

for information about how to obtain the triplet data.

If the system gets decommissioned use

registercloudguest –clean

before terminating the instance. This will ensure that the system gets removed from SCC and is no longer counted against your subscription.

We hope this new feature is useful and allows you to shorten the time spent waiting for updates to be transferred.