capm3 decouple os-images-info and os-image-server output ConfigMap

Closes #2257 (closed)

This MR addresses the design issue described in #2257 (closed) : currently, in workload clusters the information that we use for capm3 (in particular the SHA256 of the selected image) is coming from the management cluster context (output configmap of os-image-server unit), which

This MR resolves this problem by breaking the confusion between:

• (A) what is the authoritative information for images in workload context: this has to be based on running the os-images-infos unit in the sylva-units release for this workload cluster
• (B) what images are served by the os-image-server in mgmt cluster context

To achieve this:

• evolve sylva-capi-cluster (sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster!635 (merged)) and os-image-server (sylva-projects/sylva-elements/helm-charts/os-image-server!138 (merged)) components, so that:
  • the "output configmap" from os-image-server will define a capm3_os_image_server_images dict
  • sylva-capi-cluster will be able to use this dict to check that the checksum of the images selected for capm3 are present in capm3_os_image_server_images
• in workload-cluster unit definition for cluster unit, we pass two things to sylva-capi-cluster:
  • (A) in os_images the content of the os-images-infos ConfigMap (from the os-images-infos unit of the workload cluster)
  • (B) as capm3_os_image_server_images, a Kyverno-cloned copy of the output configmap coming from os-image-server (mgmt cluster context), reflecting what capm3 OS images are actually served

This MR depends on:

• sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster!635 (merged)
• sylva-projects/sylva-elements/helm-charts/os-image-server!138 (merged)

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	capd, capo, capm3
🚀	Bootstrap Provider	kubeadm (alias kadm), rke2
🐧	Node OS	ubuntu, suse
🛠️	Deployment Options	light-deploy, dev-sources, ha, misc, maxsurge-0
🎬	Pipeline Scenarios	Available scenario list and description

• 🎬 preview ☁️ capd 🚀 kadm 🐧 ubuntu

• 🎬 preview ☁️ capo 🚀 rke2 🐧 suse

• 🎬 preview ☁️ capm3 🚀 rke2 🐧 ubuntu

• ☁️ capd 🚀 kadm 🛠️ light-deploy 🐧 ubuntu

• ☁️ capd 🚀 rke2 🛠️ light-deploy 🐧 suse

• ☁️ capo 🚀 rke2 🐧 suse

• ☁️ capo 🚀 kadm 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 rolling-update 🛠️ ha 🐧 ubuntu

• ☁️ capo 🚀 kadm 🎬 wkld-k8s-upgrade 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 rolling-update-no-wkld 🛠️ ha,misc 🐧 suse

• ☁️ capo 🚀 rke2 🎬 sylva-upgrade-from-1.3.x 🛠️ ha,misc 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🐧 suse

• ☁️ capm3 🚀 kadm 🐧 ubuntu

• ☁️ capm3 🚀 kadm 🎬 rolling-update-no-wkld 🛠️ ha,misc 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🎬 wkld-k8s-upgrade 🛠️ ha 🐧 suse

• ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🎬 sylva-upgrade-from-1.3.x 🛠️ ha 🐧 suse

• ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 suse

Global config for deployment pipelines

• autorun pipelines
• allow failure on pipelines
• record sylvactl events

Notes:

• Enabling autorun will make deployment pipelines to be run automatically without human interaction
• Disabling allow failure will make deployment pipelines mandatory for pipeline success.
• if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.