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

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

Dependencies

• Depends on feat: extend datumctl with installable service plugins datumctl#198 (plugin dispatch foundation) — go.mod currently uses a replace directive pointing at that PR's worktree; the directive should be removed and replaced with a release tag once that PR merges.

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.

[scotwells]

📋 Real-world UX issue from a user enabling compute

Heads up — we got a user report that surfaces a confusing first-run experience with the enablement flow, and I've traced it end-to-end via the staging audit logs. Sharing here since the fix touches this plugin.

What the user saw:

% datumctl compute instances list
Compute is not enabled for project "personal-project-153fe986".
Would you like to request access? [y/N]: y
Requesting access to compute for project "personal-project-153fe986"...
Error: requesting compute access: serviceentitlements.services.miloapis.com "compute" already exists

From their perspective this looks like a flat-out failure. In reality, their first attempt succeeded — compute was enabled.

What actually happened (from the audit trail):

1. First run created the entitlement successfully. ✅
2. But the backend takes a short while (~minutes in this case) to mark it Ready.
3. During that window, the CLI's "is compute enabled?" check keys off the entitlement's Ready status, not its existence — so it kept reporting "not enabled" and re-offering to request access.
4. Each retry tried to create the entitlement again and hit a 409 already exists, which we surfaced as a raw, scary error.

Why it matters for the product: the very first thing a new user does is turn compute on, and today that happy path can look broken even when it worked. The error message also leaks an internal resource name (serviceentitlements.services.miloapis.com) that means nothing to a user.

Proposed fix (branch fix/compute-entitlement-pending-state, built off this PR's branch): teach the enablement check to distinguish three states instead of two —

• not requested → offer to request access (today's behavior)
• requested but still activating → tell the user it's in progress and to try again in a moment (no re-prompt, no error)
• active → proceed

…and treat a 409 already exists as "already requested, activation pending" rather than a fatal error. Net result: the user sees a calm "enablement in progress, hang tight" message instead of a stack of confusing failures.

Happy to fold this into this PR or send it as a follow-up — whichever you prefer. 🙏

[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.