Summary
Compute should only watch and reconcile projects that have actively enabled the Compute service, by integrating with the Milo service catalog. Today it engages every project on the platform, regardless of whether anyone in that project has turned Compute on.
Why this matters
When any project becomes ready anywhere on the platform, Compute immediately opens a live connection and starts caching that project's resources — whether or not the customer ever enabled Compute. That has a few real downsides:
- Customers who never enabled Compute are still treated as Compute tenants. There's no clean line between "this project exists" and "this project is a Compute customer."
- It doesn't scale with actual usage. Every ready project costs a standing watch connection and memory, so Compute's footprint grows with the size of the whole platform instead of with the number of real Compute users.
- Enablement and behavior are disconnected. A project can be reconciled by Compute with no corresponding entitlement, which makes enablement, quota, and (eventually) billing harder to reason about.
Gating on entitlement makes "enabling Compute" a real, meaningful action: Compute engages a project when the customer opts in, and lets go when they opt out.
Proposed change
Integrate Compute with the Milo service catalog so a project is engaged only while it has an active entitlement to Compute, and is cleaned up when that entitlement is revoked or removed.
Milo's service catalog already models this (a project with an active ServiceConsumer for a service = actively enabled), and milo-os/service-catalog#38 introduces a reusable, operator-agnostic library for exactly this "engage only while enabled" pattern. Compute is the intended first adopter, so much of this is adoption rather than net-new mechanism.
Acceptance criteria
Notes
Design details — which entitlement signal to key off, the teardown/ownership contract, and rollout sequencing — will be settled in a follow-up RFC before task-level breakdown.
References
- milo-os/service-catalog#38 — reusable consumer-scoped projection library ("engage consumer projects only while the service is enabled")
- Current discovery gates only on project readiness, with no entitlement check:
initializeClusterDiscovery (cmd/main.go), Milo multicluster provider wiring, DiscoveryConfig
- Related: 1.0 work-breakdown "common-services foundation / service catalog registration"
Summary
Compute should only watch and reconcile projects that have actively enabled the Compute service, by integrating with the Milo service catalog. Today it engages every project on the platform, regardless of whether anyone in that project has turned Compute on.
Why this matters
When any project becomes ready anywhere on the platform, Compute immediately opens a live connection and starts caching that project's resources — whether or not the customer ever enabled Compute. That has a few real downsides:
Gating on entitlement makes "enabling Compute" a real, meaningful action: Compute engages a project when the customer opts in, and lets go when they opt out.
Proposed change
Integrate Compute with the Milo service catalog so a project is engaged only while it has an active entitlement to Compute, and is cleaned up when that entitlement is revoked or removed.
Milo's service catalog already models this (a project with an active
ServiceConsumerfor a service = actively enabled), and milo-os/service-catalog#38 introduces a reusable, operator-agnostic library for exactly this "engage only while enabled" pattern. Compute is the intended first adopter, so much of this is adoption rather than net-new mechanism.Acceptance criteria
Notes
Design details — which entitlement signal to key off, the teardown/ownership contract, and rollout sequencing — will be settled in a follow-up RFC before task-level breakdown.
References
initializeClusterDiscovery(cmd/main.go), Milo multicluster provider wiring,DiscoveryConfig