Revisit crossplane keycoak provider deployment logic to allow pulling the image from a registry mirror
What does this MR do and why?
This MR comes in several commits adressing various needs discovered during its developement
Use configured registry mirror for crossplane provider for keycloak (initial MR objective)
For that purpose, we introduce a named template that derives the first mirror_url configured in registry_mirrors corresponding to a given registry
Since the keycloak-crossplane-provider image will not only be pulled by containerd, but also by the crossplane operator, we also have to configure this operator with registryCaBundleConfig.
Change keycloak provider deployment logic
The previous change however revealed a small issue in current provider deployment:
When crossplane helmrelease is configured with
provider:
packages:
- xpkg.upbound.io/crossplane-contrib/provider-keycloak:v2.12.1
It'll install the provider on its own and create the corresponding provider.pkg.crossplane.io named crossplane-contrib-provider-keycloak
We were then updating this provider in crossplane-provider-keycloak unit here
However, when the url changes as in this pipeline:
provider:
packages:
- 172.20.136.39/proxy_cache_xpkg.upbound.io/crossplane-contrib/provider-keycloak:v2.12.1
The corresponding provider name changes to proxycachexpkg-upbound-io-crossplane-contrib-provider-keycloa (see resource here)
Consequently the crossplane-provider-keycloak will fail with the following error as it does not provide a complete object:
crossplane-provider-keycloak 2025-12-16T12:16:37Z False Provider/crossplane-system/crossplane-contrib-provider-keycloak dry-run failed (Invalid): Provider.pkg.crossplane.io "crossplane-contrib-provider-keycloak" is invalid: [spec.package: Required value, <nil>: Invalid value: "null": some validation rules were not checked because the object was invalid; correct the existing errors to complete validation]...
In order to avoid this misconfiguration an properly manage the lifecycle of the provider object, we stop configuring the keycloak provider in crossplane HelmRelease, and do it only in crossplane-provider-keycloak unit instead (this is done in a specific commit)
Add healthCheckExpression for crossplane provider
crossplane provider exposes a status that is not compatible with kstatus, and corresponding deployment has a dynamic name, so we add healthCheckExpression to properly check the status of this provider:
status:
conditions:
- lastTransitionTime: "2025-12-16T10:54:51Z"
message: 'Package runtime health is "False" with message: post establish runtime
hook failed for package: provider package deployment is unavailable with message:
Deployment does not have minimum availability.'
observedGeneration: 1
reason: UnhealthyPackageRevision
status: "False"
type: Healthy
- lastTransitionTime: "2025-12-16T10:51:03Z"
observedGeneration: 1
reason: ActivePackageRevision
status: "True"
type: Installed
currentIdentifier: 172.20.136.39/proxy_cache_xpkg.upbound.io/crossplane-contrib/provider-keycloak:v2.12.1
currentRevision: proxycachexpkg-upbound-io-crossplane-contrib-provi-51fb83eea863
resolvedPackage: 172.20.136.39/proxy_cache_xpkg.upbound.io/crossplane-contrib/provider-keycloak:v2.12.1
Related reference(s)
Closes #3309 (closed)
Test coverage
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 |
|
| Target platform | Can be used to select specific deployment environment (i.e real-bmh for capm3 ) |
-
🎬 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🚀 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-from-1.5.x🛠️ ha🐧 ubuntu -
☁️ capo🚀 rke2🎬 sylva-upgrade-from-1.5.x🛠️ ha,misc🐧 ubuntu -
☁️ capo🚀 rke2🛠️ ha,misc🐧 ubuntu -
☁️ capo🚀 rke2🛠️ ha,misc,openbao🐧 suse -
☁️ capo🚀 rke2🐧 suse🎬 upgrade-from-prev-tag -
☁️ capm3🚀 rke2🐧 suse -
☁️ capm3🚀 kadm🐧 ubuntu -
☁️ 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🎬 sylva-upgrade-from-1.5.x🛠️ ha🐧 suse -
☁️ capm3🚀 rke2🛠️ misc,ha🐧 suse -
☁️ capm3🚀 rke2🎬 sylva-upgrade-from-1.5.x🛠️ 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.