metal3: inject oci_registry_extra_ca_certs in ipa-downloader for IPA image OCI artifact download (fix air-gapped use-case)
Related to #4136
Context: !7985 (merged) includes a change of behavior where the metal3 ironic-ipa-downloader initContainer fetches the IPA image from an OCI artifact; this created a regression for air-gapped deployment because nothing was in place to automatically use an internal OCI registry mirror.
This MR ensures that this works in air-gapped deployments:
- fetch the OCI artifact from the OCI/container registry mirror
- include the CA certs from
oci_registry_extra_ca_certsin the ironic-ipa-downloader initContainer
Some of this is achieved thanks to a postRender, discussion is in progress with @nbelouin who contributes to the Suse upstream chart so that we don't need a postRender at some point in the future.
Testing
Two environments having a registry_mirrors entry for registry.suse.org.
-
in my local dev env
✅ :$ k -n metal3-system logs metal3-ironic-5f7484f6dc-jsj6r ironic-ipa-downloader |grep -3 "manifest fetch" + get_oci_tarball 172.20.136.39/proxy_cache_registry.opensuse.org/isv/suse/edge/containers/images/ironic-python-agent:3.0.8 + local image_ref=172.20.136.39/proxy_cache_registry.opensuse.org/isv/suse/edge/containers/images/ironic-python-agent:3.0.8 + local manifest_json ++ oras manifest fetch 172.20.136.39/proxy_cache_registry.opensuse.org/isv/suse/edge/containers/images/ironic-python-agent:3.0.8 + manifest_json='{ "schemaVersion" : 2, "mediaType" : "application/vnd.docker.distribution.manifest.list.v2+json", ...but this isn't a full test because on my dev env, the PVC was already populated
-
in CI with a capo scenario with
🟢 metal3, this tests the deployment in capo infra- while testing this, we hit an interop bug betwee
orasand Harbor (details below) - this has been solved in this MR by configuring CI, only for this artifact, to use an alternate non-Harbor registry
- -> depends on sylva-projects/sylva-elements/ci-tooling/ci-deployment-values!462 (merged)
- while testing this, we hit an interop bug betwee
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 | Deployment option list and description | |
| 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 |
|
| Disabled 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 |
|
| Target platform | Can be used to select specific deployment environment Available platform list and description | |
| Pipeline control | autorun, manual or blocking. Can be used to override global config and start a deployment pipeline the required way |
-
🎬 preview☁️ capd🚀 kadm🐧 ubuntu -
🎬 preview☁️ capo🚀 rke2🐧 suse -
🎬 preview☁️ capm3🚀 rke2🐧 ubuntu -
☁️ capd🚀 kadm🛠️ light-deploy🐧 ubuntu -
☁️ capd🚀 rke2🛠️ light-deploy🐧 suse -
☁️ capo🚀 rke2🟢 mgmt:metal3🐧 suse -
☁️ capo🚀 rke2🐧 suse -
☁️ capo🚀 rke2🐧 leapmicro -
☁️ capo🚀 kadm🐧 ubuntu -
☁️ capo🚀 kadm🐧 ubuntu🟢 neuvector,mgmt:harbor -
☁️ capo🚀 rke2🎬 rolling-update🛠️ ha🐧 ubuntu -
☁️ capo🚀 kadm🎬 wkld-k8s-upgrade🐧 ubuntu -
☁️ capo🚀 rke2🎬 rolling-update-no-wkld🛠️ ha🐧 suse -
☁️ capo🚀 rke2🎬 sylva-upgrade🛠️ ha🐧 ubuntu -
☁️ capo🚀 rke2🎬 sylva-upgrade-from-1.6.x🛠️ ha,misc🐧 ubuntu -
☁️ capo🚀 rke2🛠️ ha,misc🐧 ubuntu -
☁️ capo🚀 rke2🛠️ misc🐧 ubuntu🟢 mgmt:harbor🔴 neuvector -
☁️ capo🚀 rke2🛠️ ha,misc,openbao🐧 suse -
☁️ capo🚀 rke2🐧 suse🎬 upgrade-from-prev-tag -
☁️ capm3🚀 rke2🐧 suse -
☁️ capm3🚀 kadm🐧 ubuntu🏗️ virt-leaseweb -
☁️ capm3🚀 ck8s🐧 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🎬 upgrade-from-prev-release-branch🛠️ ha🐧 suse -
☁️ capm3🚀 rke2🛠️ misc,ha🐧 suse -
☁️ capm3🚀 rke2🎬 sylva-upgrade🛠️ ha,misc🐧 suse -
☁️ capm3🚀 kadm🎬 rolling-update🛠️ ha🐧 suse -
☁️ capm3🚀 ck8s🎬 rolling-update🛠️ ha🐧 ubuntu -
☁️ capm3🚀 rke2|okd🎬 no-update🐧 ubuntu|na -
☁️ capm3🚀 rke2🐧 suse🎬 upgrade-from-release-1.5 -
☁️ capm3🚀 rke2🐧 suse🎬 upgrade-to-main
Global config for deployment pipelines
- autorun pipelines
- allow failure on pipelines
- record sylvactl events
Notes:
- Enabling
autorunwill make deployment pipelines to be run automatically without human interaction - Disabling
allow failurewill make deployment pipelines mandatory for pipeline success. - if both
autorunandallow failureare 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.