Move the model-route access modal off the deprecated allowed_users
policy/field onto the unified allowed_principals + principals surface,
persisting everything through a single /access POST.
- "specific users" radio now uses allowed_principals; a returned legacy
allowed_users value is normalized so existing routes still select it.
- derive the picker's selection and the full grant set from `principals`
in GET /access (fall back to legacy `items` if a backend doesn't
return principals yet).
- save as `principals`: the principal-based override sends its staged
set; the user picker maps its selection to USER-kind grants and
preserves any non-user grants from the snapshot (no longer sends
`users`).
- guard saving before the GET seeds principals (would wipe grants);
share the ALLOWED_PRINCIPALS_POLICY constant.
- AccessControlFormData: `users` optional, add `principals`.
The two management pages now pass ``mine=true`` to their list APIs.
With multi-tenant cluster_access in place an Org Owner would
otherwise see rows that came in via cross-Org grants — usable but
read-only — and editing/deleting them would 403 from the backend.
Restricting the management lists to rows the caller's scope owns
keeps the UX honest. PV-create / GPU-instance-create pickers still
query without ``mine`` so usable cross-Org clusters and types are
selectable there.
Two changes that together restore the per-row Edit / Delete menu
for non-admin users:
- ``templateActions`` drops the blanket ``access: 'canSeeAdmin'``
gate on every menu item. With the gate on, non-admin callers got
an empty filtered menu, so clicking the "..." did nothing.
- The management page passes ``mine=true`` to the list API. The
endpoint now drops Global rows for non-admin callers (rows they
can't edit anyway), so the dropdown shows up only on rows the
caller may manage. The GPU-instance create picker reuses the
same API without ``mine``, keeping Global presets visible there.
The route was gated on ``canSeeAdmin`` so only platform admins ever
saw Storage Types in the sidebar. But the backend route
(``gpu_instance_persistent_volume_types``) is tenant-scoped — Org
owners can create / list their own — so hiding the menu from them
left an admin-defined feature reachable only by URL.
Relax to ``canSeeOrgAdmin`` to match. OSS keeps the platform-admin-only
behaviour (predicate defaults to ``isPlatformAdmin``); the enterprise
access extension widens it to the current-org owner.
The catalog was gated on ``currentStep === startStep`` so it would
re-appear at step 1 whenever ``providerHint`` skipped the catalog (e.g.
GPU Service's "Add a Kubernetes Cluster" empty-state CTA). Result: the
configure step rendered the catalog *plus* the Name/Description/Advanced
form together, with Kubernetes shown as already selected — confusing
and ugly.
Pin the catalog to step 0 explicitly. ``startStep`` was only used to
seed ``currentStep``, so it's inlined into the ``useState`` initializer
to keep the "skip the catalog when providerHint is set" intent in one
place. Pre-selecting a provider now correctly lands the user straight
on the configure form alone.
Two follow-ups to the GPU Service gating:
- In Personal-Org view the access extension was stripping
canSeeAdmin/canSeeOrgAdmin but leaving canSeeGpuService at its
admin-shortcut value, so platform admins switched into Personal
still saw the menu even though Personal scope can't host a K8s
cluster. Mirror the probe result through sessionStorage so the
extension can fall back to the strict cluster-availability signal
in that branch.
- The empty-state CTA now reads 'Add a Kubernetes Cluster' and, on
click, opens the cluster-create flow with Kubernetes preselected
via clusterSession.providerHint. ClusterCreate consumes the hint
on mount: it seeds extraData.provider and starts at the configure
step instead of the provider catalog, so the user lands one click
closer to the form they actually need.
GPU Service today only schedules on Kubernetes clusters; Docker / cloud
clusters can't host the CRDs. Without any awareness of that, Org
members whose Org has no K8s cluster (and no cluster_access grant on
one) saw a menu they couldn't use and a form that bottomed out with
backend errors.
Two changes lock the UX down:
- Boot probes the caller's cluster list once and stashes
hasKubernetesCluster in initialState. A new canSeeGpuService
predicate gates the menu — admins and Org owners always see it
(they can add the cluster); everyone else only sees it when a
reachable K8s cluster actually exists.
- The instances page filters its own cluster list to Kubernetes
before deciding what to show. With nothing reachable we render the
Deployments-style 'No clusters available. Add a Kubernetes cluster
to get started.' empty state and hide the create-instance CTA;
admins and Org owners additionally get the 'Add cluster' button
that jumps to cluster management.
OwnerPrincipalIdField was reading currentClusterAtom, which no callers
ever wrote — so every form submission ended up with
owner_principal_id=null and the backend rejected non-admins with
"Only platform admin can create global ...". Pin the field to
currentOrganizationId instead (the Org the caller is acting under).
Cluster ownership is the wrong source: a cluster_access grant lets one
Org schedule on another Org's cluster, but the new resource is still
owned by the caller's Org, and the backend enforces
owner_principal_id == ctx.current_principal_id.
Also drops the dead currentClusterAtom.
- New k8s_pod_spec form sections (image credentials, node selector,
gpu vendor overrides) under k8s_options, replacing the legacy flat
k8s_volume_mounts list. UI keys aligned to the backend wire shape
(snake_case k8s_options + camelCase inside).
- System default container registry is pre-filled into the first image
credential when creating a new cluster; empty username/password are
coerced to null on submit to match the Optional[str] backend schema.
- Register cluster flow supports multi-runtime selection gated by the
cluster's gpuVendorOverrides: non-override vendors stay single-select
with an inline hint; multi-add only opens once an override vendor is
picked, and non-override cards become disabled in that state.
- Manifest URL emits multiple ?runtime= params; check-env step combines
per-vendor commands; downstream steps are disabled when no vendor is
selected.
- Pre-validate gpuVendorOverrides at save time (non-empty selector, no
duplicates across vendors, no key clash with base nodeSelector) so
the user sees the error before hitting the manifest endpoint.
- Misc: dark-mode background of the k8s_pod_spec / volume mount titles
no longer clashes with the drawer; cluster Steps no longer leaks the
internal showModules/showForms props to the DOM.
