feat(crossplane): derived CR names as an opt-in (derivedNames), p&t twin v0.10.9

[patrick-hermann-sva]

Helm side of stuttgart-things/flux#506. The flux machinery profile and xplane-crossplane-catalog (0.7.0, kcl#297) name every Provider and Configuration by the path Crossplane derives from its package. These helmfiles still used short names for four of them.

Changes

• New state value derivedNames, default false. With --state-values-set derivedNames=true, each entry that has a derivedName uses it:

  today	with derivedNames=true
  provider-opentofu	upbound-provider-opentofu
  provider-kubeconfig	stuttgart-things-provider-kubeconfig-xpkg
  namespace	stuttgart-things-crossplane-configurations-namespace
  volume-claim	stuttgart-things-crossplane-configurations-volume-claim

  The providers template computes the name in one place, so the CR, its DeploymentRuntimeConfig, the serviceAccountTemplate and the ClusterRoleBinding always change together.

• crossplane-contrib-function-patch-and-transform goes from v0.10.8 to v0.10.9, the same version as its short-named sibling (catalog 0.7.0). The CR name doesn't change, so this is an in-place upgrade. The digest is identical on both mirrors, which is the same pattern function-kcl already runs healthy on kind5.

Why opt-in and not the new default

On a live cluster, a rename damages it either way:

• Helm replaces the CR. Deleting the old Provider or Configuration also deletes its CRDs/XRDs and every managed resource or XR on them.
• Both names coexist. Two CRs for one source is a duplicate Lock node, and every package goes Healthy=False.

kind_machinery (ansible) pins this repo through helm_repo_ref. It checks for CRs under the old names first, and only then sets the flag (see the ansible PR). Four consumers apply these helmfiles from main with no such check:

• ansible plays/kind-machinery-test.yaml
• platform-engineering-showcase: the Taskfile.yaml and bundles/platform.yaml.gotmpl (defaults to ref: main)
• stuttgart-things ansible/exec/labda/dev3-kind/deploy.yaml

As the default, the rename would reach them unannounced. As an opt-in, they keep their names until someone flips the flag on purpose.

Checked beforehand: a Helmfile presync hook can't do the check. It doesn't receive the kubeconfig passed with --kubeconfig (KUBECONFIG is empty in the hook, and kubectl falls back to localhost:8080).

Migration note ⚠️

• Fresh clusters: set derivedNames=true.
• Existing clusters with the short names: do not set the flag. Either rebuild the cluster, or migrate by hand. By hand means for each package: delete the old CR (knowing what happens to its CRDs and the objects on them) and create the new one in the same step. Keep the kind machinery clusters (kind4/kind5) on the old names until they're rebuilt (one Backstage run).
• Once the unpinned consumers above are pinned or move to the new names, the default can flip in a separate PR.

Verification

• helmfile template on crossplane-providers and crossplane-config:
  • Without the flag, and with derivedNames=false, the output is byte-identical to main, except the p&t tag.
  • With the flag, only the names in the table change: CR, DRC, SA and CRB.
• Fresh kind cluster (Crossplane from cicd/crossplane.yaml.gotmpl, then both helmfiles with derivedNames=true):
  • 5 Providers, 2 Configurations and 7 Functions, all Healthy.
  • opentofu runs with DRC upbound-provider-opentofu, ServiceAccount upbound-provider-opentofu, and ClusterRoleBinding crossplane-upbound-provider-opentofu.
  • A second helmfile diff shows no changes.

Refs stuttgart-things/flux#506

🤖 Generated with Claude Code