Repository navigation
feat(azure/savings-plans): wire SP rec collection into scheduler #17
Description
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)
Activity
cristim commentedon May 28, 2026
Verification: cannot-verify-autopilot. PR LeanerCloud/cloud-commitments-cli#592 (the linked PR) only added the Azure Savings Plans ServiceClient and wired it into provider.go + services.go dispatch. The scheduler's Azure rec-collection path does not call it: GetRecommendations in providers/azure/services/savingsplans/client.go returns an empty slice, and there is no scheduler probe file for Azure SP. The commitmentopts SP probe equivalent for Azure has not been added. The scheduler wiring described in this issue has not landed on origin/feat/multicloud-web-frontend.
feat(azure/savings-plans): wire SP rec collection into scheduler (#59…
cristim commentedon Jun 8, 2026
Note: PR LeanerCloud/cloud-commitments-cli#809 (merged) only wired the scheduler goroutine slot - providers/azure/services/savingsplans/client.go GetRecommendations still returns an empty slice (Azure Benefits Recommendations API is in preview), so no Azure SP recommendation reaches the user yet, and the commitmentopts SP probe equivalent is still missing. This issue correctly remains OPEN to track the real implementation when the preview API stabilizes.
IAmJSD commentedon Oct 23, 2026
Claiming: working on this
IAmJSD commentedon Oct 23, 2026
Released: needs an owner decision, no code change made. @cristim
What I found on current main (a14dc8f, pinned providers/azure 3def3f8):
savingsplans.Client.GetRecommendations(Benefit Recommendations API). The provider'sGetAllRecommendationsincludes it, and the scheduler's Azure paths (collectAzureForAccount,collectAzureAmbient) collect it. A throwaway unit test showed an SP rec survivesconvertRecommendations. The earlier "returns an empty slice" comments describe the pre-fix(server): advisory lock released on the request context strands a task type in permanent already_running #373 stub.all-upfront, but Azure's payments areupfront/monthly.Compute, while go#503 moved toCompute_Savings_Plan.Decision needed: close the collection half as done (go#373), and either delete
probe_azure.goor build it properly. Building it needs a per-provider probe-row migration, a currency source, corrected payment/SKU values, an AWS/Azure failure split and an API/UI follow-up. It could only be verified against Azure after the deploy pause. I'm happy to do the deletion as a small PR if you choose that.cristim commentedon Oct 23, 2026
@IAmJSD thank you for checking this, let's build it properly.