Skip to content

feat(ui): compute workloads portal plugin - #198

Draft
kevwilliams wants to merge 2 commits into
mainfrom
feat/portal-plugin
Draft

feat(ui): compute workloads portal plugin#198
kevwilliams wants to merge 2 commits into
mainfrom
feat/portal-plugin

Conversation

@kevwilliams

@kevwilliams kevwilliams commented Jul 28, 2026

Copy link
Copy Markdown

What this is

A read-only operational dashboard for compute.datumapis.com (Workload list/detail, Instance detail), shipped as a standalone Module Federation remote under cloud-portal's Portal Plugin System — the portal discovers and loads it at runtime, no cloud-portal PR or deploy required.

Lives at ui/consumer/workloads/, alongside a new top-level split:

  • ui/consumer/ — portal plugins this service ships for the portal to load
  • ui/provider/ — reserved for UI building blocks this service exposes to other services' plugins or the portal itself (empty for now)

Relationship to cloud-portal #1315

An earlier, unmerged cloud-portal PR (datum-cloud/cloud-portal#1315) built this same dashboard as native portal routes. This plugin ports that functionality here instead, rewriting the parts that depended on portal-internal code:

PR #1315 (portal-internal) This plugin
Generated SDK (@/modules/control-plane/compute) Plain fetch() against /api/proxy/…
useResourceWatch (watch-stream) useQuery with refetchInterval (~10s) polling
Server-loader RBAC gate (runDetailLoader) Client-side catch of a 403 → inline restricted state
Portal path config (paths.config.ts) useParams()/useNavigate() from the shared react-router singleton

Zod schemas, adapters, cli-section.tsx, and compute.helper.ts ported over near-verbatim — see the plugin's own README for the full breakdown. cloud-portal #1315 stays open as reference for now.

Screencast.From.2026-07-29.12-44-00.mp4

Scope — v1 is read-only

This is a CLI-first service: workload creation, deployment, scaling, restarts, and deletion all happen via datumctl compute …. This plugin only gives operators visibility into what's already running — no deploy/edit/delete forms, no Activity/Metrics/Settings tabs yet.

Why draft

This is a first pass, "roughing it into place" — functional and verified locally, but not yet polished (e.g. WorkloadDetail's manifest entry is missing an explicit requirements.permissions block that WorkloadList/InstanceDetail both have — needs a decision on whether that's intentional).

Test plan

  • cd ui/consumer/workloads && bun install && bun run typecheck && bun run build — all pass, emits dist/remoteEntry.js
  • Manually smoke-tested against a local cloud-portal checkout (Tier 0 static registration, PORTAL_PLUGINS=compute=http://localhost:7778) — Workloads nav item and pages render
  • Test against a project with real Workload/Instance resources (only verified against an empty/no-data state so far)
  • Resolve the WorkloadDetail permissions gap noted above

Read-only operational dashboard for compute.datumapis.com (Workload
list/detail, Instance detail) shipped as a Module Federation remote
under the cloud-portal Portal Plugin System — https://github.com/datum-cloud/cloud-portal/blob/main/docs/enhancements/portal-plugin-system.md

Lives at ui/consumer/workloads/, alongside a new ui/ split:
- ui/consumer/ — portal plugins this service ships for the portal to load
- ui/provider/ — reserved for UI building blocks this service exposes to
  other services' plugins or the portal itself (empty for now)

Ports the functionality of the unmerged cloud-portal PR #1315 (native
portal routes) into a standalone plugin instead, rewriting the parts
that depended on portal-internal code:
- Generated SDK calls -> plain fetch() against /api/proxy
- useResourceWatch (watch-stream) -> useQuery with refetchInterval polling
- Server-loader RBAC gate -> client-side 403 handling, inline restricted state
- Portal path config -> react-router hooks scoped to the plugin's own mount

v1 is read-only by design (CLI-first: workload creation/mutation stays
in datumctl) — list + detail views only, no deploy/edit/delete forms.

Verified: typecheck and build both pass, produces dist/remoteEntry.js.
Manually smoke-tested against a local cloud-portal (Tier 0 static
registration) — nav item and pages render.
- Redesign the workload list as a card grid with a fleet summary stat
  strip, replacing the plain table.
- Redesign workload and instance detail pages with breadcrumbs, a
  shared serif PageTitle, a disabled-tab bar for unimplemented views,
  and a shared stat strip.
- Replace the workload detail's instance table with a card grid.
- Add a datumctl CLI command reference card to instance detail.
- Bump the Workloads nav item's manifest `order` to sit under Service
  Accounts (paired with a cloud-portal nav-merge change).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant