Repository navigation
fix(gcp): match SKUs by whole tier token and explicit region - #244
Conversation
A SKU with no ServiceRegions priced every region and the tier test was a plain substring, so db-n1-standard-1 matched db-n1-standard-16 and STANDARD matched STANDARD_HA. Cloud SQL, Memorystore and Compute Engine now share skumatch: the tier must appear as a whole token and the region must be listed explicitly. Cloud Storage is left for a follow-up because it is being edited elsewhere.
|
@coderabbitai full review |
✅ Action performedFull review finished. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (9)
Included review availability: This review used your included allowance. 0 included reviews remain after this review. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughThe change adds shared helpers for matching SKU description tokens and service regions. Cloud SQL, Compute Engine, and Memorystore use these helpers. Tests cover token boundaries, region matching, and Cloud SQL pricing extraction. ChangesGCP SKU Matching
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to This change makes GCP SKU matching stricter, so tiers and regions are matched exactly. No actionable merge-blocking risk was identified. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
…gnostic The catalog leaves the region list empty for global SKUs, so an empty list with GeoTaxonomy.Type GLOBAL applies in every region. Empty regions with any other or a missing taxonomy still match nothing.
What
Cloud SQL, Memorystore and Compute Engine SKU matching now (1) requires the tier or machine type to appear as a whole token in the description and (2) applies a SKU to a region only when that region is listed in
ServiceRegions, or when the list is empty andGeoTaxonomy.TypeisGLOBAL. Both rules live in the newproviders/gcp/internal/skumatch.Why
A SKU with nil
ServiceRegionspriced every region, and the tier test was a plain substring (db-n1-standard-1matcheddb-n1-standard-16,STANDARDmatchedSTANDARD_HA).The catalog docs say an empty region list means global: "This field is empty for Global SKUs since they are associated with all Google Cloud regions" (cloud.google.com/billing/v1/how-tos/catalog-api) and "Empty for Global skus, which are associated with all Google Cloud regions" (services.skus.list reference). The SDK's
GeoTaxonomy.TypedocumentsGLOBAL,REGIONALandMULTI_REGIONAL(google.golang.org/api v0.274.0, cloudbilling/v1/cloudbilling-gen.go:611-624). So an empty list is trusted only with aGLOBALtaxonomy. Empty regions withREGIONAL,MULTI_REGIONAL, unspecified or a missing taxonomy is ambiguous and no longer matches.Behaviour change
Callers get no match where a region-less SKU of unknown scope used to match every region.
Limits
Real catalog descriptions do not contain tiers or machine types (for example "Cloud SQL for MySQL: Regional - 1 vCPU + 3.75GB RAM in Americas", see cloud.google.com/skus/sku-groups/cloud-sql-cud-eligible-skus). Real lookups are therefore unchanged by this PR and still return no pricing for the token-matched services; the whole-token matching is correct on synthetic strings only. This PR does not claim a price correction. The real-data matching problem is tracked separately. Cloud Storage is untouched because #205 edits that file.
Verification
InRegion(inverted GLOBAL check; REGIONAL treated as global) each fail the skumatch tests.go vet ./...,go test ./...,golangci-lint run ./...in providers/gcp all exit 0.Refs #97