Repository navigation
fix(crossplane-providers): install provider-helm as the dependsOn-derived CR (one CR, not two) - #154
Merged
Merged
Conversation
…ived CR
provider-helm was installed here as `provider-helm` from xpkg.upbound.io.
Four Configurations (crossplane-configurations bootstrap/{platform,
flux-init,cni,vault-config}) dependsOn provider-helm from
xpkg.crossplane.io, from which the package manager derives a second
Provider CR `crossplane-contrib-provider-helm`. Two Provider CRs for the
same package fight over the releases.helm.m.crossplane.io CRD — the loser
is stuck UnhealthyPackageRevision, which fails the machinery bootstrap's
`kubectl wait provider --all --for=condition=Healthy` gate.
Verified on a fresh LabUL machinery cluster. Unlike the function-kcl
cross-mirror pair (functions own no CRDs, benign), providers own CRDs, so
there must be exactly ONE provider-helm CR.
Fix: name this install `crossplane-contrib-provider-helm` and source it
from xpkg.crossplane.io — exactly what the dependsOn derives. The provider
helmfile runs before the Configurations, so this CR exists first; the
dependsOn then finds it (carrying the runtimeConfigRef + cluster-admin
DeploymentRuntimeConfig for InjectedIdentity) instead of adding its own.
One CR, healthy.
ClusterProviderConfigs are named `in-cluster`, independent of the provider
CR name, so nothing referencing the provider by config name changes.
kind1 is unaffected until an explicit re-apply (no ArgoCD auto-sync; the
release is a one-shot from bootstrap).
Refs stuttgart-things/crossplane-configurations#147
This was referenced Jul 23, 2026
patrick-hermann-sva
added a commit
that referenced
this pull request
Sep 19, 2026
…endsOn (#163) provider-kubernetes, provider-proxmox-bpg and the xpkg.crossplane.io twins of function-kcl and function-patch-and-transform were never installed explicitly. The package manager pulled them in for the Configurations' dependsOn, at the newest version the constraint allowed that day, so two clusters built from the same commit differed. A throwaway machinery cluster (u26-kindtest, 2026-09-19) got provider-kubernetes 1.3.1, proxmox-bpg 1.19.3, kcl 0.12.3 and p&t 0.10.11 next to u26-kind3's 1.2.1, 1.18.0, 0.12.2 and 0.10.8. Each is now listed under exactly the name and source the package manager derives from the dependsOn, as provider-helm already is (#154), so the dependency finds this object instead of adding its own. Versions are u26-kind3's. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes stuttgart-things/crossplane-configurations#147.
Problem
provider-helmwas installed here as CRprovider-helmfromxpkg.upbound.io. Four Configurations (bootstrap/{platform,flux-init,cni,vault-config})dependsOnprovider-helm fromxpkg.crossplane.io, from which the package manager derives a second Provider CRcrossplane-contrib-provider-helm. Two Provider CRs for the same package (same digest) fight over thereleases.helm.m.crossplane.ioCRD:That fails the machinery bootstrap's
kubectl wait provider --all --for=condition=Healthygate. Verified on a fresh LabUL machinery cluster.provider-kubernetesdoes not hit this — it is (deliberately) not installed here and comes solely viadependsOn, so there is only one CR.Unlike the function-kcl cross-mirror pair (functions own no CRDs → benign, per crossplane-configurations CLAUDE.md), providers own CRDs, so there must be exactly one provider-helm CR.
Fix
Name this install
crossplane-contrib-provider-helmand source it fromxpkg.crossplane.io— exactly what thedependsOnderives. The provider helmfile runs before the Configurations, so this CR exists first; thedependsOnthen finds it (carrying theruntimeConfigRef+ cluster-adminDeploymentRuntimeConfigneeded for InjectedIdentity) instead of adding its own. One CR, healthy.Blast radius
ClusterProviderConfigs are namedin-cluster, independent of the provider CR name — nothing referencing the provider by config name changes.DeploymentRuntimeConfig, ServiceAccount and ClusterRoleBinding all derive from$p.name, so they rename with it, consistently.crossplane-providersrelease is a one-shot from bootstrap (revision 1, 2026-07-10). A future re-apply moves it to the fixed single-CR state.