capm3/os-images: add os-image-server-clear-old-ingresses one-shot kube-job to handle Ingress name transition (!6154) · Merge requests · Sylva-projects / sylva-core

Context

!6005 (merged) introduced the ability of serving OS images from previous Sylva releases, for use by workload clusters.

This implied adding -<image SHA sum> suffix to the name of Ingresses to make them collision-free.

Problem

Unfortunately a case of "collision" remains:

two Ingresses can't point to the same (host, path) tuple (there is a check preventing that in ingress-nginx admission webhook)
when upgrading from a previous Sylva version to main, we have the following situation
- an "old" Ingress exists for image foo with path x-y-z, named foo
- the os-image-server as configured in main, will now try to create an Ingress for image foo, with path x-y-z, named foo-<image SHA sum>
... the ingress-nginx webhook will fail (two Ingresses for same host-path tuple)

In that case we get this kind of error:

Warning UpgradeFailed Helm upgrade failed for release os-images/os-image-server with chart os-image-server@2.6.2:
 failed to create resource:
 admission webhook "validate.nginx.ingress.kubernetes.io" denied the request:
 host "_" and path "/opensuse-15-6-hardened-rke2-1-31-0.5.15.raw" is already defined 
   in ingress os-images/os-image-server-opensuse-15-6-hardened-rke2-1-31

Solution

To address this, this MR adds a simple one-shot kube-job unit that deletes all Ingresses.

This evolution addresses two practical scenarios:

developers doing upgrades from main (before !6005 (merged)) to current main
upgrades from Sylva 1.4 or 1.5 to main, enabling the functionality introduced by !6005 (merged) (as in !5829)

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`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	`light-deploy`, `dev-sources`, `ha`, `misc`, `maxsurge-0`, `logging`, `no-logging`, `cilium`
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type

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.

Edited Nov 21, 2025 by Thomas Morin

capm3/os-images: add os-image-server-clear-old-ingresses one-shot kube-job to handle Ingress name transition

Context

Problem

Solution

CI configuration

Global config for deployment pipelines

Merge request reports