[harbor] No way to disable registry upload purging — every surface that could is Helm-owned and reverts #3972

The gap

When a background maintenance task inside the Harbor registry misbehaves, there is no supported way to turn it off. Every surface that could express it is generated by something upstream of it:

Harbor CR "registry" (apps.cozystack.io/v1alpha1)   <- the only object an operator owns
  └─ HelmRelease harbor-registry                     <- generated by Kustomization "managed"
      └─ HelmRelease harbor-registry-system          <- rendered by harbor-registry's chart
          └─ Deployment + ConfigMap harbor-registry-registry

kubectl explain harbor.spec accepts eight fields — core, database, host, jobservice, redis, registry, storageClass, trivy — and harbor.spec.registry exposes only resources and resourcesPreset. storage.maintenance.uploadpurging is not reachable from any of them.

Patching further down doesn't hold: edits to harbor-registry-system, to the Deployment, or to the ConfigMap are reverted on the next reconcile. A Flux postRenderer has nowhere to attach that survives, because the HelmRelease it would attach to is itself Helm-rendered.

Why the ConfigMap route is also wrong

Worth stating separately, because it looks like the obvious escape hatch: harbor-registry-registry's config.yml is a single YAML blob, so patching it means restating the whole file. That both freezes chart defaults at whatever was copied and commits the Redis password to git, since it appears in plaintext in that file.

Concrete instance

We hit this with the registry's S3 upload purger crash-looping (67 restarts in 30 hours) on a SeaweedFS-backed bucket — goharbor/harbor#23795, root cause is distribution/distribution#4713, which is fixed upstream but not in the distribution 2.8.x fork Harbor currently ships.

Being straight about the value here: the panic itself is an upstream bug and will go away when Harbor picks up the fix. This issue is not asking Cozystack to work around that. What the incident exposed is that while we waited, there was no lever — a background task was taking down the registry roughly hourly and the platform offered no supported way to stop it. We ended up writing an hourly GC job against the object store instead, which is a workaround for a missing knob rather than for the bug.

Suggested fix, in preference order

1. Expose storage.maintenance under harbor.spec.registry. Narrow, matches the shape of the existing resources passthrough.
2. A general valuesOverride on the application CRs. Broader and more useful, since this is not the first time a Cozystack CR could not express a setting the software beneath it requires. Precedent exists — Add option for overriding fluxcd values values-fluxcd  #169 added values-fluxcd for the same class of problem.

Option 2 is the one we'd actually use, but it is also the bigger design decision; option 1 unblocks this case on its own.

Environment

Cozystack v1.6.2, Harbor 2.15.1, registry v2.8.3-25-g086d3c33, SeaweedFS object storage.