feat(ui): compute workloads portal plugin - #198
Merged
Conversation
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).
…ds plugin Bring the workloads plugin closer to the design mocks now that real metrics aren't wired up yet: - Seeded sparkline placeholder on workload list cards and workload detail instance cards, ported from the design's sparkline.js pencil script. - Instance Locations map on the workload detail page, reusing the same dot-matrix world map asset and card layout as cloud-portal's Active POPs map (no location markers — compute's region codes aren't in that map's lat/lng table).
staff-portal's /customers/resources page now supports plugin-declared resource types (portal.resource/platform) instead of every type being hardcoded by a staff-portal engineer. This is the first plugin to use it: it exposes no page or component at all, just a manifest declaring the compute.datumapis.com Workload GVK, a label, and an icon — staff-portal runs the search itself and renders the rows. Supersedes an earlier standalone /workloads page in staff-portal (this session, not previously released): once Workload could show up as a Type filter on the existing Resources list, the hand-rolled page had strictly worse UX (no real search/sort/pagination) for the same data. Lives under ui/provider/ (compute-authored UI for a host other than cloud-portal), not ui/consumer/.
kevwilliams
marked this pull request as ready for review
August 10, 2026 17:39
Nothing built, published, or hosted ui/consumer/workloads's static assets anywhere — service-catalog's fan-out needs a real HTTPS assets.baseURL to create a ConsumerPortalPlugin, and there wasn't one. - New Dockerfile: bun build stage -> nginx-unprivileged serving dist/. Verified locally (docker build + run, plugin-manifest.json and remoteEntry.js both serve 200) including under the hardened securityContext the Deployment uses (read-only rootfs, non-root, dropped capabilities, emptyDir mounts for nginx's writable dirs). - New ui/consumer/workloads/config/: Deployment+Service+HTTPRoute, published as its own kustomize bundle (mirrors datum-storybook's pattern — the platform's dominant convention for "app repo publishes its own deployable static frontend bundle" — not echo's inline-in-infra pattern). HTTPRoute attaches to the shared external-gateway per environment, same as cloud-portal/datum-storybook; no dedicated Gateway. - .github/workflows/publish.yaml: two new jobs (image + kustomize bundle) using the same reusable workflows compute's apiserver already calls — publish-docker.yaml already supports context/dockerfile-path inputs. - service-configuration.yaml: sets spec.userInterface.consumer.assets.baseURL to the new staging-only hostname, entitlement None for now. Flagged inline: this component applies identically to every environment's milo control plane today (no per-env patch exists), so this also lands in production's control plane — low-risk short-term since production's cloud-portal has no platform registry source wired up yet, but real per-environment parametrization is still owed. Companion infra PR wires the environment-side (Gateway listener, Kustomization, staging-only for the same reason the credential rollout was staging-only).
4 tasks
Matches the established split (see cloud-portal's config/base, which has no namespace.yaml either): the app repo's bundle only carries workload resources; the namespace itself is infra's responsibility (apps/compute-workloads-plugin/base/namespace.yaml, companion infra PR).
Per review on #215: - No reason to expose this plugin publicly — the browser never talks to a plugin origin directly (cloud-portal's server fetches the manifest/ assets and proxies them via /api/plugins/<slug>/...). Drops the HTTPRoute entirely; the Deployment now terminates TLS itself via a cert-manager CSI server cert (key-usages: server auth, datum-control-plane ClusterIssuer) — the same pattern milo's own apiserver, ClickHouse, and the OTel collector already use for internal-only TLS. Verified locally: docker build/run with a temporary self-signed cert mounted the same way the CSI volume will be, curl -k and openssl s_client both confirm the server block and cert subject are correct. - Move config/components/consumer-ui-plugin (was ui/consumer/workloads/config) so it lives alongside compute's other kustomize components (matches config/components/service-catalog's kind: Component convention) and gets folded into compute-manager's own Deployment set via its existing components: list (companion infra change) — same cluster, same compute-system namespace, no new Flux Kustomization or OCIRepository. - Bump the reusable workflow pin to v1.20.0 per review (matches cloud-portal's own pin). Drop the separate kustomize-bundle publish job entirely: once the Deployment is folded into compute-manager, a separate bundle publish never actually gets read by anything, so it can't pin an image tag that matters. Accept a floating :latest tag with imagePullPolicy: Always instead — this is a static asset server, not a GitOps-tracked control-plane binary. - service-configuration.yaml: assets.baseURL is now the internal Service DNS name (compute-workloads-plugin.compute-system.svc.cluster.local), not a public hostname. Cluster-local DNS resolves correctly in whatever environment compute-manager deploys to, so (unlike the previous public-hostname draft) this needs no per-environment override. Sets assets.caBundle to datum-control-plane-ca's public cert (fetched from the live datum-control-plane-trust-bundle ConfigMap, non-sensitive) so cloud-portal trusts the CSI-issued cert without disabling verification. Verified: kustomize build config/components/consumer-ui-plugin standalone, and the full compute-manager composition (base/manager + all its components including this new one) — both images present with no cross-contamination, no build errors.
mattdjenkinson
previously approved these changes
Aug 10, 2026
- Rename compute-workloads-plugin -> compute-consumer-ui-plugin throughout (Deployment/Service/labels/image/CSI dns-names/baseURL). "Workloads" is one page within compute's consumer plugin, not the plugin's identity — and this leaves room for a symmetric compute-provider-ui-plugin later. - Replace nginx with Bun's own static file server (serve.ts): drops an entire second runtime/technology for what's a few lines of fetch handling, and this project is already Bun-based end to end. Verified locally the same way as before — docker build/run with a temporary self-signed cert, curl -k for real assets (200), unknown paths (404), and a path-traversal attempt (404, confirms the path normalization actually blocks it). - Drop assets.caBundle entirely. Checked plugin-fetch.ts: withCaBundle() is a no-op when caBundle is unset, falling through to Bun's default TLS trust — and cloud-portal's own Deployment already sets NODE_EXTRA_CA_CERTS platform-wide (both staging and production) pointing at the same datum-control-plane-trust-bundle the plugin's CSI cert chains to. The explicit caBundle was redundant with trust cloud-portal already has. - CI pin: plain `@v1.20.0` instead of the SHA-pinned form.
feat: build, publish, and deploy the compute workloads plugin bundle
scotwells
approved these changes
Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 loadui/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:
@/modules/control-plane/compute)fetch()against/api/proxy/…useResourceWatch(watch-stream)useQuerywithrefetchInterval(~10s) pollingrunDetailLoader)paths.config.ts)useParams()/useNavigate()from the sharedreact-routersingletonZod schemas, adapters,
cli-section.tsx, andcompute.helper.tsported 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 explicitrequirements.permissionsblock thatWorkloadList/InstanceDetailboth 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, emitsdist/remoteEntry.jsPORTAL_PLUGINS=compute=http://localhost:7778) — Workloads nav item and pages renderWorkloadDetailpermissions gap noted above