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

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 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 by Francois Eleouet

Merge request reports

Loading