Skip to content

feat(gcp/cuds): surface Compute Engine resource-based CUDs that cross-attribute to Cloud SQL / Memorystore CPU usage #4

Open

Description

@cristim

Summary

Follow-up from LeanerCloud/cloud-commitments-cli#649 (closes LeanerCloud/cloud-commitments-cli#640). LeanerCloud/cloud-commitments-cli#649 made GCP Cloud SQL / Cloud Storage / Memorystore PurchaseCommitment advisory-only because their spend-based CUDs have no public create-API. That decision was correct for the spend-based product, but there is a separate, genuinely actionable optimization angle:

Google cross-attributes Compute Engine resource-based CUDs onto the underlying compute used by some managed services (Cloud SQL, Memorystore, Dataflow workers, GKE-on-CE nodes). The user CAN'T buy a "Cloud SQL CUD" via API, but they CAN buy a Compute Engine resource-based CUD (vCPU/RAM) for the region where their Cloud SQL or Memorystore instances run, and Google will automatically apply that discount to those workloads' underlying compute charges.

The Compute Engine resource-based CUD path has a programmatic API: compute.regionCommitments.insert (and globalCommitments for memory-only / GPU shapes).

What this issue is

Surface Compute Engine resource-based CUD recommendations sized to cover the CPU/RAM used by:

  • Cloud SQL instances in the same region
  • Memorystore for Redis / Valkey instances in the same region
  • (optionally) Dataflow worker pools, GKE node pools running on CE

The PurchaseCommitment path for these recommendations would use the existing GCP Compute Engine CUD purchase code (which is already implemented for vanilla CE — verify by reading providers/gcp/services/compute/).

What this issue is NOT

Suggested approach

  1. Recommender wiring: GCP's Recommender API category google.cloud.recommender.ComputeEngineCommitmentRecommender already surfaces these resource-based CUD recommendations as a single category covering all the underlying compute. Check whether the existing CUDly GCP recommender integration includes that category or only the vanilla CE one.
  2. Cross-attribution notation: when a CUD recommendation's projected coverage spans Cloud SQL / Memorystore / Dataflow workloads, surface that in the recommendation card so the user understands what they're actually buying. The frontend would show: "Buy Y vCPU + Z GB resource-based CUD in us-east1 — currently covers: 2 Cloud SQL instances + 1 Memorystore Redis + 4 GKE nodes" with the cross-attribution metadata.
  3. Purchase path: reuse the existing CE CUD purchase code at providers/gcp/services/compute/client.go (or wherever the resource-based CUD purchase already exists). No new SDK needed.
  4. Tests: assert that the resource-based-CUD recommendation surfaces with cross-attribution metadata for a mock account that has both CE and Cloud SQL workloads.

Acceptance criteria

  • GCP recommendation collection includes Compute Engine resource-based CUDs sized to cover Cloud SQL / Memorystore / Dataflow underlying compute
  • Recommendation surface (UI + email) explicitly notes the cross-attribution coverage so the user knows what's actually being discounted
  • PurchaseCommitment uses the existing CE CUD API (no advisory-only path)
  • Tests cover the cross-attribution metadata round-trip

Cross-references

Severity / Effort

  • Severity: low — current advisory-only behavior is correct; this is upside, not a bug
  • Effort: large — needs Recommender API extension, recommendation-card UX, and the cross-attribution data model

Activity

  1. cristim commented on Oct 17, 2026

    @cristim
    MemberAuthor

    Decision needed (one line): should CUDly build Compute resource-based CUD recommendations with Cloud SQL and Memorystore cross-attribution metadata? It needs a new common.Recommendation field plus platform UI and email work, well over 400 lines. Safe default: park until #493 (Cloud SQL and Memorystore CUD removal) merges, then re-scope to a metadata-only slice in pkg/common. Marking status/needs-info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions