fix(backupstrategy-controller): gate the default MongoDB strategy on bootstrap - #3815

What this PR does

Closes #3814.

Unblocks a fresh install of main. Since #3562 the backupstrategy-controller chart renders one default Strategy CR ungated, and that makes the whole release fail on a cluster where its CRDs are not yet applied:

Helm install failed for release cozy-backup-controller/backupstrategy-controller
resource mapping not found for name: "cozy-default-mongodb"
no matches for kind "MongoDB" in version "strategy.backups.cozystack.io/v1alpha1"

The chart ships its own eight strategy.backups.cozystack.io CRDs as ordinary templates, since templates/crds.yaml globs definitions/*.yaml, and Helm pre-applies only a crds/ directory. Helm then resolves every document in the release manifest through the cluster's RESTMapper in Build() before it applies any of them, so an ungated Strategy CR has no mapping on the first install, Build() fails, and the release applies zero objects, including the CRDs that would have made the mapping resolve.

Nothing recovers from that. Every retry renders the same manifest, so it is permanent rather than a race, and Helm's kind sorter cannot help because it orders the apply and the failure is before the apply. The install log shows Warning InstallFailed 43s (x36 over 20m) and then Install failed (no retry).

Why the seven siblings never hit this

Each of them gates on a resolved $bucketName, which is empty until the COSI BucketClaim status is reconciled, so they are simply absent from the first render. By the time DefaultObjectsGate forces a second revision the CRDs from revision 1 exist and the mapping resolves.

That gate is documented as "the CR needs the bucket name", and it silently doubles as the CRD-ordering guard. MongoDB genuinely does not need the bucket name, the template argues that correctly, so the gate was left off and the accidental protection went with it. This gates it too, for the ordering reason rather than the value, and records that reason in the template so the next bucket-independent strategy keeps it.

Convergence is unchanged. DefaultObjectsGate already routes apps.cozystack.io/MongoDB to cozy-default-mongodb and forces a revision once any routed object is missing, which is exactly how the seven siblings materialise today.

Why this was invisible

tests/rendering_test.yaml asserted count: 1 for the MongoDB template under a case named "bootstrap window (no resolvable bucket name)", so the defect was codified as the expected behaviour and shipped green. helm-unittest has no RESTMapper and cannot see the consequence. That assertion is flipped here, with the ordering reason written next to it.

It was also masked in CI until yesterday by #3806. StreamVisitor.Visit returns immediately on a validation error but only continues on a mapping error, so the OpenAPI defect aborted the manifest stream at the first document and the mapping check was never reached. #3808 fixed that and this surfaced underneath it.

Screenshots

Not applicable.

Downstream repositories

• No downstream repository is affected by this change

Testing

Verified by rendering both windows, since the whole bug is which documents appear in the first render and a cluster adds nothing to that.

Before, bootstrap window: one Strategy document, MongoDB, alongside the eight not-yet-applied CRDs. After: none. With backupStorage.bucketNameOverride=b, which stands in for a resolved BucketClaim: all eight, MongoDB included.

helm template bsc packages/system/backupstrategy-controller | grep -c '^kind: MongoDB$'

helm unittest packages/system/backupstrategy-controller passes, 4 suites, 18 tests.

Follow-up, not in this PR

The durable fix is to stop shipping these CRDs as templates and split definitions/ into a backupstrategy-controller-crds package with a dependsOn edge, which is the convention six other packages already follow. That cannot be a hotfix: none of the eight definitions carries helm.sh/resource-policy: keep, so the upgrade that removes them from this chart's manifest would have Helm delete the eight CRDs and cascade-delete every live Strategy CR on existing clusters. It needs the keep annotation shipped a release ahead.

Release note

fix(backupstrategy-controller): gate the default MongoDB backup strategy on the bootstrap window, so a fresh platform install no longer fails with "no matches for kind MongoDB" and applies nothing

Summary by CodeRabbit

• Bug Fixes

  • Prevented the default MongoDB backup strategy from rendering before the required S3 storage configuration is available.
  • Improved first-install reliability by avoiding premature strategy resource creation.

• Tests

  • Updated bootstrap validation to confirm the MongoDB strategy is omitted until a bucket name is resolved.