Skip to main content

Channels​

The Elemental Operator allows subscription to one or more ManagedOSVersionChannels, to automatically populate a list of ManagedOSVersions ready to be consumed to build new ISOs using a SeedImage, or to upgrade existing Elemental nodes to new OS versions using the ManagedOSImage.

A channel is normally distributed as an OCI container image, but it is also possible to reference the URI of a JSON file directly containing a list of ManagedOSVersion. Note that the best practice is to distribute channels using images, so that distribution is consistent with all other images needed by the Elemental Operator. This can be beneficial for example when deploying in an Airgapped environment.

This syncer will fetch a json from url and parse it into valid ManagedOSVersion resources.

managed-os-version-channel-json.yaml
apiVersion: elemental.cattle.io/v1beta1
kind: ManagedOSVersionChannel
metadata:
name: elemental-versions
namespace: fleet-default
spec:
options:
URI: "https://raw.githubusercontent.com/rancher/elemental-docs/main/examples/upgrade/versions.json"
Timeout: "1m"
type: json

Available Channels​

Elemental maintains a list of channels that can be used out of the box.

Base OSBaseOS VersionFlavorChannel URI
SL Micro6.0Baseregistry.suse.com/rancher/elemental-channel/sl-micro:6.0-base
SL Micro6.0Bare-metalregistry.suse.com/rancher/elemental-channel/sl-micro:6.0-baremetal
SL Micro6.0KVMregistry.suse.com/rancher/elemental-channel/sl-micro:6.0-kvm
SL Micro6.0RTregistry.suse.com/rancher/elemental-channel/sl-micro:6.0-rt

Flavors​

Elemental distributes different OS flavors that can better fit specific use cases.

FlavorDescriptionReference
BaseA minimal image that can be used as base to build custom images.Source
Bare-metalContains bare-metal and usability packages. Can be used for any generic workload.Source
KVMReady to be used with KVM. Contains QEMU Guest agent by default.Source
RTLike bare-metal images, but includes a Real-Time kernel.Source

Channels lifecycle and best practices​

Once a new ManagedOSVersionChannel is created, the Elemental Operator will periodically sync the channel provided JSON list, and convert it to new ManagedOSVersions.
All synced ManagedOSVersions will be owned by the ManagedOSVersionChannel. Deleting the ManagedOSVersionChannel will lead to the deletion of all ManagedOSVersions on cascade.

Note that the ManagedOSVersionChannel supports automatic clean up of no longer in sync ManagedOSVersions, when the ManagedOSVersionChannel.spec.deleteNoLongerInSyncVersions option is enabled.

When a ManagedOSVersion is scheduled for deletion, a finalizer will make sure that there is no active reference on any ManagedOSImage.

If a ManagedOSVersion can not be deleted, you can find out by which resources it is referenced:

kubectl -n fleet-default get managedosimages -l elemental.cattle.io/managed-os-version-name=my-deleted-os-version

When using multiple channels it's important to keep a proper naming strategy to always have a quick, human readable reference on the owned ManagedOSVersions.
It is recommended to name any channel as: {BaseOS}-{BaseOSVersion}-{Flavor}.

This should allow the user to use the ManagedOSVersion name as the specific Elemental build version of the image, while keeping a reference on the Base OS and Base OS version from the parent channel.
On the Rancher UI this will look something like the following image:

Channel naming

Making your own Channels​

The only requirement to make your own custom syncer is to make it output a JSON file to /data/output and keep the correct JSON structure.

The file is a JSON array containing ISO and Container entries.
Each entry in the array is mapped 1:1 with a ManagedOSVersion object.

"type": "iso" entries must contain a bootable Elemental ISO and are used by SeedImages, while "type": "container" entries are used by ManagedOSImage for Elemental upgrades.

If in doubt, the elemental-channels project can be used as a reference implementation on how to build and maintain your own channels.

When creating new entries, be mindful of the naming strategy you choose, in order to avoid collisions with other channels, since they may end up syncing different ManagedOSVersion with the same name.
A best practice is to use the convention: {Flavor}-{Version}-{Type}
A sample of the JSON format is as follows:

versions.json
[
{
"metadata": {
"name": "my-flavor-v0.1.0"
},
"spec": {
"version": "v0.1.0",
"type": "container",
"metadata": {
"upgradeImage": "foo/bar-os:v0.1.0-myflavor",
"displayName": "Foo Bar OS - My Flavor"
}
}
},
{
"metadata": {
"name": "my-flavor-v0.1.0-iso"
},
"spec": {
"version": "v0.1.0",
"type": "iso",
"metadata": {
"uri": "foo/bar-iso:v0.1.0-myflavor",
"displayName": "Foo Bar ISO - My Flavor"
}
}
}
]