Repository navigation
feat(crossplane): let providers carry env and resources, and slow provider-opentofu down - #164
Merged
Merged
Conversation
…vider-opentofu down Every reconcile of a Workspace is a full tofu init/plan/apply. At the image defaults - poll 10m per resource, sync 1h across all of them - six Workspaces held u26-kind3 at load 8 on 8 cores, tofu and the Proxmox provider binary together around 400% CPU, for Vault configuration that does not change. The cluster paid for it in leader elections: kube-controller-manager, kube-scheduler, crossplane-rbac-manager and openebs each restarted ~3950 times in 39 days, and the machinery play failed intermittently on rollout gates. provider-opentofu now runs with poll 1h / sync 6h and real limits. The values template gained optional env and resources for any provider; a DeploymentRuntimeConfig is emitted when rbac, env or resources are set, so nothing changes for the providers that set none. env rather than args: args in a DeploymentRuntimeConfig replace the image defaults instead of adding to them, and every flag has an env var. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
provider-proxmox-bpg is an upjet provider: every reconcile of a managed resource shells out to terraform with the bpg/proxmox provider binary. At the default poll of 10m and nine Proxmox resources on u26-kind3 that is a terraform run roughly every 70 seconds, and measured on the VM it was the LARGEST single CPU consumer - larger than provider-opentofu, which this branch already slowed down. Same treatment: PROVIDER_POLL 1h, PROVIDER_SYNC 6h and real limits. A VM that Crossplane itself manages does not drift between polls. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
patrick-hermann-sva
added a commit
to stuttgart-things/ansible
that referenced
this pull request
Sep 20, 2026
…vals) (#1240) Picks up stuttgart-things/helm#164: provider-opentofu and provider-proxmox-bpg run with poll 1h / sync 6h and real limits, instead of the image defaults that kept u26-kind3 at load 8 on 8 cores and made every leader-election component restart thousands of times. The only files that differ from 4ba3965 are the crossplane-providers helmfile and its values template. 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
1 participant
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.
Why
Every reconcile of an OpenTofu
Workspaceis a fulltofu init/plan/apply. At the image defaults —--poll=10mper resource,--sync=1hacross all of them — the six Workspaces on u26-kind3 (vault-auth and kubeconfig entries for homerun2-test1, seed-labda-1 and schmetterpause-rehearsal1) kept that VM at load 8 on 8 cores, with tofu and the Proxmox provider binary together around 400% CPU, for Vault configuration nobody edits.The cluster paid for it where it hurts: everything doing leader election lost its lease and restarted, over and over.
The visible damage was a machinery play failing on rollout gates at random points, and a sops-secrets-operator that reconciled only while it happened to be up (
Error retrieving lease lock ... context deadline exceeded).Change
envandresourcesper provider. ADeploymentRuntimeConfigis now emitted whenrbac,envorresourcesare set; providers that set none render exactly as before (checked: provider-helm's DRC is unchanged).CROSSPLANE_OPENTOFU_PROVIDER_POLL=1h,CROSSPLANE_OPENTOFU_PROVIDER_SYNC=6hand real limits (requests 100m/256Mi, limits 2/2Gi).env, not args: args in a
DeploymentRuntimeConfigreplace the image defaults rather than adding to them, and every flag of this provider has an environment variable. The flags and their defaults were read from the running binary (crossplane-opentofu-provider --help), not guessed;--max-reconcile-rateis already 1, so frequency was the only lever.Checked
helmfile diffagainst u26-kind3 shows exactly one changed object: the provider-opentofu DRC gains the env and resources block. Nothing else moves.Not in this PR
The real fix is fewer Workspaces: stuttgart-things/crossplane-configurations#482 replaces the vault-auth ones with provider-vault, which keeps no state and needs no tofu run at all. This is the cheap half that helps today.
🤖 Generated with Claude Code
Update: provider-proxmox-bpg too
Measuring on the VM after the opentofu change showed the larger consumer is provider-proxmox-bpg, an upjet provider that shells out to terraform with the
bpg/proxmoxbinary for every managed resource. Nine Proxmox resources at the default--poll=10mis a terraform run roughly every 70 seconds. It now gets the same treatment:PROVIDER_POLL=1h,PROVIDER_SYNC=6hand limits.helmfile diffagainst u26-kind3 now shows two changes: the provider-opentofu DRC gains env and resources, and provider-proxmox-bpg gains aruntimeConfigRefplus its own DRC (it previously useddefault, so nothing it relies on is lost).