Context
PR LeanerCloud/cloud-commitments-cli#592 added the Azure Savings Plans ServiceClient (provider client + dispatch wiring). The scheduler does not yet call it for rec collection.
Work
Wire ServiceSavingsPlans into the scheduler's Azure rec-collection path, mirroring how AWS Savings Plans recs are collected (via the Cost Explorer centralized path, or -- once the Azure Benefits Recommendations API exits preview -- via the client's GetRecommendations).
Also add the commitmentopts SP probe equivalent for Azure (mirroring probe_savingsplans*.go for AWS).
Depends on
LeanerCloud/cloud-commitments-cli#592 (must land first)
refs LeanerCloud/cloud-commitments-cli#473
Findings from the 2026-09-02 codebase audit
Added by an automated audit of 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd (tip of origin/main). Each item below was reported by one reviewer and independently confirmed by a second that did not write it. Full report: docs/audits/codebase-audit-2026-09-02.md.
A05-009 (medium)
Worth knowing before anyone starts this: the Azure commitmentopts SP probe already exists as internal/commitmentopts/probe_azure.go (212 lines plus 304 lines of tests), but it is unreachable. ProbeAzure and DefaultAzureProbers have no non-test caller, and the doc comment points at Service.probeAndPersistAzure, which does not exist -- probeAndPersist (service.go:76) only ranges over s.probers, and AzureSPProber cannot join that set because Probe takes an azcore.TokenCredential rather than an aws.Config. The consequence today is that Validate("azure", "savingsplans", ...) always takes the permissive-true branch, so a reader auditing whether Azure SP term/payment combos are validated concludes they are. The wiring work here is therefore either an Azure sibling of probeAndPersist or deleting the file; leaving it as-is is the worst option. (audit finding A05-009)
Context
PR LeanerCloud/cloud-commitments-cli#592 added the Azure Savings Plans
ServiceClient(provider client + dispatch wiring). The scheduler does not yet call it for rec collection.Work
Wire
ServiceSavingsPlansinto the scheduler's Azure rec-collection path, mirroring how AWS Savings Plans recs are collected (via the Cost Explorer centralized path, or -- once the Azure Benefits Recommendations API exits preview -- via the client'sGetRecommendations).Also add the
commitmentoptsSP probe equivalent for Azure (mirroringprobe_savingsplans*.gofor AWS).Depends on
LeanerCloud/cloud-commitments-cli#592 (must land first)
refs LeanerCloud/cloud-commitments-cli#473
Findings from the 2026-09-02 codebase audit
Added by an automated audit of
3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd(tip oforigin/main). Each item below was reported by one reviewer and independently confirmed by a second that did not write it. Full report:docs/audits/codebase-audit-2026-09-02.md.A05-009 (medium)
Worth knowing before anyone starts this: the Azure
commitmentoptsSP probe already exists asinternal/commitmentopts/probe_azure.go(212 lines plus 304 lines of tests), but it is unreachable.ProbeAzureandDefaultAzureProbershave no non-test caller, and the doc comment points atService.probeAndPersistAzure, which does not exist --probeAndPersist(service.go:76) only ranges overs.probers, andAzureSPProbercannot join that set becauseProbetakes anazcore.TokenCredentialrather than anaws.Config. The consequence today is thatValidate("azure", "savingsplans", ...)always takes the permissive-true branch, so a reader auditing whether Azure SP term/payment combos are validated concludes they are. The wiring work here is therefore either an Azure sibling ofprobeAndPersistor deleting the file; leaving it as-is is the worst option. (audit finding A05-009)