A fresh install of the platform fails, and it fails at the same release every time.
Helm install failed for release cozy-backup-controller/backupstrategy-controller
with chart cozy-backupstrategy-controller: unable to build kubernetes objects from
release manifest: resource mapping not found for name: "cozy-default-mongodb"
namespace: "" from "": no matches for kind "MongoDB" in version
"strategy.backups.cozystack.io/v1alpha1"
The backupstrategy-controller chart ships its own CustomResourceDefinitions as ordinary templates: templates/crds.yaml renders every file under definitions/*.yaml through .Files.Glob. There is no crds/ directory, so Helm treats them like any other manifest rather than installing them ahead of the release. That works as long as the same release does not also contain an instance of one of those kinds, because Helm builds the objects from the rendered manifest before anything is applied, and building a custom resource needs a REST mapping that only exists once its definition is in the cluster.
templates/strategy-mongodb-default.yaml renders such an instance, and unlike its siblings it renders unconditionally. Counting top-level if guards in the four default-strategy templates: strategy-cnpg-default has one, strategy-mariadb-default has one, strategy-altinity-default has one, strategy-mongodb-default has none. The file says so in its own header, and gives the reason: the psmdb operator resolves the backup target against the source PerconaServerMongoDB rather than against a bucket, so there is no populated $bucketName to gate on.
So the three gated strategies stay out of the first render and appear on a later reconcile, by which time their definitions are established. The ungated one goes into the very release that is still creating the definition it needs.
Both halves arrived together in #3562, dff56aa99, on 12 August. Nightly has been red on install since before that, for a different reason that #3808 has now removed, so this became the visible failure only once the earlier one was out of the way. That is also why the window looks wider than the commit.
One thing I did not verify: I am taking the "no $bucketName to gate on" reasoning from the template's own comment rather than from a rendered manifest, so the claim that the siblings are absent from the first render is inference from their guards, not an observation of a real first install.
The shape of the fix is a scheduling question rather than a correctness one. Either the definitions move somewhere Helm installs first, or the unconditional instance gains a condition that is false until its definition exists, or it moves out of this release entirely. Which of those is right depends on how the rest of the platform expects to acquire these definitions, which is why I am reporting rather than proposing.
A fresh install of the platform fails, and it fails at the same release every time.
The
backupstrategy-controllerchart ships its own CustomResourceDefinitions as ordinary templates:templates/crds.yamlrenders every file underdefinitions/*.yamlthrough.Files.Glob. There is nocrds/directory, so Helm treats them like any other manifest rather than installing them ahead of the release. That works as long as the same release does not also contain an instance of one of those kinds, because Helm builds the objects from the rendered manifest before anything is applied, and building a custom resource needs a REST mapping that only exists once its definition is in the cluster.templates/strategy-mongodb-default.yamlrenders such an instance, and unlike its siblings it renders unconditionally. Counting top-levelifguards in the four default-strategy templates:strategy-cnpg-defaulthas one,strategy-mariadb-defaulthas one,strategy-altinity-defaulthas one,strategy-mongodb-defaulthas none. The file says so in its own header, and gives the reason: the psmdb operator resolves the backup target against the source PerconaServerMongoDB rather than against a bucket, so there is no populated$bucketNameto gate on.So the three gated strategies stay out of the first render and appear on a later reconcile, by which time their definitions are established. The ungated one goes into the very release that is still creating the definition it needs.
Both halves arrived together in #3562,
dff56aa99, on 12 August. Nightly has been red on install since before that, for a different reason that #3808 has now removed, so this became the visible failure only once the earlier one was out of the way. That is also why the window looks wider than the commit.One thing I did not verify: I am taking the "no
$bucketNameto gate on" reasoning from the template's own comment rather than from a rendered manifest, so the claim that the siblings are absent from the first render is inference from their guards, not an observation of a real first install.The shape of the fix is a scheduling question rather than a correctness one. Either the definitions move somewhere Helm installs first, or the unconditional instance gains a condition that is false until its definition exists, or it moves out of this release entirely. Which of those is right depends on how the rest of the platform expects to acquire these definitions, which is why I am reporting rather than proposing.