[Epic] Description of available images (aka ChangeLog)

[kkaempf]

Describe the solution you'd like:
[A clear and concise description of what you want to happen.]

The UI presents a selection of images (name + version) to choose from when building ISOs or triggering upgrades.

However, there's no information about the differences between images and how to choose one over the other.
Users can only choose the highest version and keep fingers crossed.

The UI should be enriched with 'ChangeLog' data, informing users about the main changes between
image versions and thus helping them to choose the right one (or to not trigger and upgrade at all).

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Traditional SUSE Linux Enterprise captures this information in 'patch' descriptions.

Proposal

Include the change log data as part of the channel information (e.g. include updates XML as part of the channel image or a channel side car image). There is a service to compute and serve a filtered updates info on demand. The input of such a service is the gap to compute: from date A to date B. Where date A and B are the build dates of the two images we aim to compare.

We could eventually precompute the XML to a different format, but if we consider on demand queries I think XML might be just fine, it is a well known and clearly structured format.

The reason to consider an on demand service to list patches is essentially because the channels does not include the list of all images that have been ever listed, so pre computing all the patches applied to certain image would only be fine if the channel keeps the history of all images which is not the case currently. Moreover we still need a strategy to serve the changelog list and once having that making it dynamic is just a small addition, the operator would require logic to serve a per image list in any case.

I envision a deployment per active channel that is owned and managed by the elemental-operator, something like a small REST API?

Tasks:

• Include build key in ManagedOSVersions metadata elemental-operator#882
• include updateinfo xml in a new set of channel images in IBS #1652
• Create a small tool to process and filter update XML files elemental-channels#52
• Precompute data at build time, a changlog per managedosversion #1654
• Expose service to display OS images changelog in elemental-operator controllers elemental-operator#890
• Include previous images in channel update, do not drop any image

[davidcassany]

• We need to include additional information in ManagedOSVersion resources:
  • Package list
  • Patches information
• We need a process to collect the patches included in each build (I'd suggest asking maintenance if they know a process)
  • Would be interesting to embed this information into image itself, so we can easily extract it at the time of channel creation.

[anmazzotti]

This issue needs to be refined further.
As for now we came up with some conclusions about packages information:

• Adding the packages list into the ManagedOSVersion is going to add too much data to the k8s resource and degrade performance
• A package list could be shipped using a "sidecar" info image, but this is making the OS release process more complex. It would be best that any information we want to display can be extracted/produced from the OS image directly.
• Providing a packages list is not really the goal of this issue (which is instead to provide a human readable summary of changes)
• Providing a list of packages can be done running rpm -qa from any OS container images, this can be documented
• We can provide this as a image feature by using ENTRYPOINT:

docker run --entrypoint "rpm" registry.suse.com/suse/sl-micro/6.0/baremetal-os-container:2.1.1-3.29 -qa

• However this won't work for ISO images, so either we include this info into the ISO image itself, or maybe we could add information on the base OS image used for the ISO (better).

Regarding patches:

• Need to find out whether adding RUN zypper --installroot /osimage patch -y is a required best practice or not. This seems to be the case for the registry.opensuse.org/opensuse/leap-micro/6.0/toolbox:latest](http://registry.opensuse.org/opensuse/leap-micro/6.0/toolbox:latest) image, as I found out latest still had some patches that could be applied.
• The output of zypper patches could be used as a human readable changelog maybe:

Refreshing service 'container-suseconnect-zypp'.
Refreshing service 'openSUSE'.
Loading repository data...
Reading installed packages...
Repository      | Name | Category    | Severity  | Interactive | Status     | Since      | Summary
----------------+------+-------------+-----------+-------------+------------+------------+---------------------------------------------------------------------------------------------
repo-main (6.0) | 9    | recommended | low       | ---         | applied    | 2024-09-03 | Recommended update for bash, libcap-ng, libselinux, libselinux-bindings, libsemanage, zypper
repo-main (6.0) | 10   | security    | critical  | ---         | not needed | -          | Security update for qemu
repo-main (6.0) | 11   | security    | moderate  | ---         | not needed | -          | Security update for wget
repo-main (6.0) | 21   | security    | important | ---         | not needed | -          | Security update for skopeo
repo-main (6.0) | 22   | security    | moderate  | reboot      | not needed | -          | Security update for ucode-intel
repo-main (6.0) | 23   | security    | important | ---         | applied    | 2024-09-03 | Security update for python311, python-rpm-macros