Integrate Harbor Configuration Operator with Dedicated Units (harbor-configuration-operator & harbor-config)

What does this MR do and why?

This MR integrates the Harbor Configuration Operator into Sylva to declaratively manage Harbor configuration (projects, proxy registries, robot accounts, etc.) via Kubernetes CRDs.

The integration introduces:

• A dedicated unit to deploy the Harbor Configuration Operator
• A separate unit to manage Harbor configuration resources (CRDs)
• Schema validation for Harbor-related values
• Helm passthrough mechanism to render and apply Harbor CR manifests

This MR also removes the setting of CONFIG_OVERWRITE_JSON (which defined OIDC configurations) done by harbor-init ks. Now, the OIDC configuration is set by HarborServer CR.

This change is done because of the error "current config is init by env variable: CONFIG_OVERWRITE_JSON, it cannot be updated" . If CONFIG_OVERWRITE_JSON is set by harbor-init , then OIDC config could not be done by harborServer.

With the removal of CONFIG_OVERWRITE_JSON, the setting "project_creation_restriction":"adminonly" was also removed which is now done by new unit named harbor-project-config

Related reference(s)

closes #2619 (closed)

Dependency on Orange-OpenSource/k8s-tz/tools/harbor-configuration-operator!557 (merged)

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 🛠️ ha 🐧 ubuntu
• ☁️ capo 🚀 rke2 🎬 sylva-upgrade-from-1.6.x 🛠️ ha,misc 🐧 ubuntu
• ☁️ capo 🚀 rke2 🛠️ ha,misc 🐧 ubuntu
• ☁️ capo 🚀 rke2 🛠️ ha,misc,openbao:penguin: 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 🎬 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 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.