Problem
The datumctl compute plugin's entitlement check pulls in go.miloapis.com/service-catalog, which transitively requires milo v0.26.1. That milo version's downstreamclient package is incompatible with how the federated-scheduling controllers use it and with controller-runtime v0.23.3 (missing Apply method; ClusterName type mismatch).
To keep the build green while stacking the CLI plugin (#113) on the federation work, go.mod carries a stopgap pin:
replace go.miloapis.com/milo => go.miloapis.com/milo v0.25.2-0.20260528192736-e4258524ad42
This couples the compute module to an older milo than service-catalog expects, which will drift and mask real incompatibilities over time.
Desired outcome
Remove the replace directive once a milo release (and matching service-catalog) exists whose downstreamclient is compatible with controller-runtime v0.23.3. After removal, go build ./... and go test ./... must stay green without the pin.
Context
Problem
The
datumctl computeplugin's entitlement check pulls ingo.miloapis.com/service-catalog, which transitively requiresmilo v0.26.1. That milo version'sdownstreamclientpackage is incompatible with how the federated-scheduling controllers use it and with controller-runtime v0.23.3 (missingApplymethod;ClusterNametype mismatch).To keep the build green while stacking the CLI plugin (#113) on the federation work,
go.modcarries a stopgap pin:This couples the compute module to an older milo than
service-catalogexpects, which will drift and mask real incompatibilities over time.Desired outcome
Remove the
replacedirective once amilorelease (and matchingservice-catalog) exists whosedownstreamclientis compatible with controller-runtime v0.23.3. After removal,go build ./...andgo test ./...must stay green without the pin.Context
feat/datumctl-compute-plugin(PR feat: datumctl compute plugin — deploy and manage workloads from the CLI #113) during the rebase ontofeat/federated-deployment-scheduling.