feat: datumctl compute plugin — deploy and manage workloads from the CLI

[scotwells]

Summary

Adds the datumctl compute plugin so developers can deploy and manage containerized workloads on Datum Cloud directly from the CLI.

Commands shipped:

• deploy — push a container image as a workload with flags or a manifest file; waits for rollout
• destroy — tear down a workload with a confirmation prompt
• status — show workload health, per-city placement summary, and the active revision
• instances — list all running instances across cities, with describe for full detail
• scale — adjust minimum replica count across all placements
• rollout — watch live rollout progress, browse revision history, and roll back to any prior revision
• restart — trigger a rolling restart of a workload or a specific city
• quota — inspect per-city instance usage and surface quota-exceeded messages
• access — show or request Compute service access for the project (see below)

Revision history is stored as a ConfigMap per workload so rollout history and rollout undo work without server-side tracking.

Service activation & access UX

Compute is enabled per project through a ServiceEntitlement, and enabling it awaits a manual approval on the provider side. The plugin gates every data command on that enablement — and until now it told the user the wrong thing at every step: it created the request, waited a fixed 15 seconds, then printed Error: and "try again in a moment" even though the request had succeeded, and pointed at datumctl services … commands that don't exist.

This branch now derives the whole experience from the entitlement's own status, so the CLI is honest in every state.

Before (verbatim):

$ datumctl compute instances
Compute is not enabled for project "datum-cloud".
Would you like to request access? [y/N]: y
Requesting access to compute for project "datum-cloud"...

Access to compute for project "datum-cloud" has been requested.
Run your command again once it becomes active.

Check status with: datumctl services list
Error: compute access is not yet active — try again in a moment

After:

$ datumctl compute instances
Compute is not enabled for project "datum-cloud".
Requesting access sends an enablement request to the service provider for approval.
Would you like to request access? [y/N]: y
Requesting access to compute for project "datum-cloud"...
⠋ Waiting for the platform to process the request... (4s)

Your request to enable compute for project "datum-cloud" has been submitted.

  Status:  Pending approval — Waiting for the service provider to approve this request.
           Approval is a manual step by the service provider and may take a while.

Check progress with:   datumctl compute access
Wait for activation:   datumctl compute access request --wait

A submitted request no longer reads as an error, pending approval is a legible waiting state, denied/unavailable states carry the platform's own explanation plus a real recovery command, and every printed command exists. New gate-exempt verbs back this up:

• datumctl compute access [-o json|yaml] — the current access state (with age and the server's message); always exits 0.
• datumctl compute access request [--message] [--renew] [--wait] [--timeout] — the explicit request verb; safe in scripts, never prompts.

Scripts get a documented exit-code contract (10–13 for not-enabled / denied-or-revoked / pending / unavailable) instead of a blanket exit 1.

The gate logic lives in a shared, service-agnostic serviceactivation package in datumctl (see Dependencies), so the next plugin adopts the flow instead of forking it. Design and rationale: docs/compute/development/rfcs/cli-service-activation.md.

Dependencies

This is a three-repo dependency chain — compute → datumctl → service-catalog — and it must be merged and re-pinned in reverse order (service-catalog first, then datumctl, then compute), replacing each branch pseudo-version with a tagged/merged release before the next merges.

• Depends on feat: extend datumctl with installable service plugins datumctl#198 (plugin dispatch foundation).
• Depends on feat(serviceactivation): shared, status-keyed service-enablement SDK datumctl#242 — the shared serviceactivation SDK. go.mod pins go.datum.net/datumctl to that PR's commit by pseudo-version. The pin also pulls datumctl's own requirements forward, notably go.miloapis.com/milo 0.26 → 0.29.3 across the whole compute module — the controller suite should be validated in CI against that bump (it is: Tests and E2E Tests are green).
• Transitively depends on feat(client): generated typed clientset for services.miloapis.com/v1alpha1 milo-os/service-catalog#50 — the generated typed clientset the SDK is built on. go.miloapis.com/service-catalog is pinned (indirect) to that PR's commit.

What's not included

• logs — telemetry service not yet implemented
• Tests — next step is adding envtest-based integration tests for each command
• cities / instance-types resource listing commands

Related

Closes #98. Design proposal in #111. Activation UX design in docs/compute/development/rfcs/cli-service-activation.md. Shared SDK: datum-cloud/datumctl#242.

[scotwells]

Context: should rollout become a verb group?

Capturing the context so we can make this call deliberately — the decision is open, including doing it before this PR merges. Not asserting a deferral.

Today restart and rollout are flat siblings under compute, and rollout is a status-watcher (≈ kubectl rollout status). As we add more rollout lifecycle operations there's a natural pull toward the kubectl mental model, where rollout is a group of verbs:

compute rollout restart    # what `compute restart` does today
compute rollout status     # what `compute rollout` does today
compute rollout undo       # rollback
compute rollout history    # revisions
compute rollout pause / resume

The tradeoff

• Moving to the grouped form is a breaking change to the surface (compute restart → compute rollout restart). Cheapest to do before this PR merges / before the plugin has real adoption — every release we wait raises the cost of moving users' muscle memory, scripts, and docs.
• With only two rollout verbs today (restart + status), the grouping is mostly cosmetic; its clear payoff lands once we ship undo / history (revision tracking) and can design the whole verb set + shared flags (--to-revision, --watch, …) in one coherent pass.
• So it's a real "now vs later" call: now = pay the design cost early but lock in the clean structure before adoption; later = avoid churn until the verbs justify it, at the cost of a harder migration.

Open design question — where does history come from?
rollout history and undo both depend on revision history of the resource, and we should decide where that lives before committing to these verbs:

• Compute-specific — compute tracks its own Workload/template revisions (à la Deployment → ReplicaSet), owned and stored by this service; or
• Generic platform capability — a shared resource-history / revisioning / audit-trail primitive that any resource type plugs into.

If the platform offers (or should offer) generic resource history, compute's rollout {history,undo} should be a thin view over that primitive, not a bespoke revision store — and that also shapes whether these verbs stay under compute or surface more generically across the CLI. This is worth resolving early because it drives both the data model behind rollout and the command surface we'd be locking in.

A signal we're already drifting toward grouping
workloads describe → "Next steps" already advertises datumctl compute rollout undo <wl>, which doesn't exist yet. Our own copy is implicitly assuming the grouped model.

If we do it now, keep restart as a hidden alias of rollout restart for a release or two so we don't break early scripts. If we defer, revisit when we pick up rollout history/undo.