kacerrandClaude Opus 5.5
7f2073f94b
The optional proxmox-token Secret (token, ca.pem) mounted at /etc/proxy-operator/proxmox, make proxmox-token-secret with content checks that never print the token, a commented proxmox-home entry in both providers configs, and config/samples/proxy_proxmox.yaml. TestLoadConfig_proxmoxSampleEntry loads the commented entry from both files, and a second test ties the sample Proxy's placement to it. docs/proxmox-provider.md is the user guide: prerequisites and privileges, cluster setup, config reference, placement, what lands on Proxmox, logging, tracing, timeouts, health check, error classes, known gaps and testing. providers-existing.md gains the proxmox column and section; architecture.md, the README, providers.md and CLAUDE.md gain their rows. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2.1 KiB
2.1 KiB
Providers
The provider documentation is split into three files so that a new provider can be specified and built from the generic rules alone, without reading how the existing ones happen to work.
- provider-contract.md: what every provider MUST, SHOULD and MAY do, which caller depends on each rule, the behaviour profiles where providers are allowed to differ, the error taxonomy, credential hygiene, testing obligations, the checklist for adding a provider, and the contract's known limits. It never names an existing provider.
- provider-spec-template.md: the questionnaire
a new provider's design answers, one entry per decision the contract leaves
open. Copy it to
docs/<type>-provider-spec.md, fill it in, and hand it to the implementer with the other two files. - providers-existing.md: how kubernetes, gcp, kvm, kvm2 and proxmox meet the contract, a table mapping each of them to every profile, their per-provider reference notes, shared gaps and proposed features.
Per-provider user guides: kvm-provider.md, kvm2-provider.md, proxmox-provider.md, gcp-vm-validation.md and gcp-in-specific-project.md.
Related sections of architecture.md: the components table, §5 what provider calls do, §10 tracing, §11 provider health checks and the "Decisions" list. The test layout is in testing.md.
Reading order for a new provider
- The contract, end to end.
- The template, filled in for the new backend; every unanswered entry is a design decision still to make.
- The appendix, for a worked example of each profile the spec chose.
- The user guide of the existing provider closest to the new one.
The single-file blueprint that preceded this split is in the git history of this path.