feat: gate GPU Service on Kubernetes cluster availability
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.
This commit is contained in:
Vendored
+6
@@ -92,6 +92,12 @@ declare namespace Global {
|
||||
interface InitialStateType {
|
||||
fetchUserInfo: () => Promise<UserInfo>;
|
||||
currentUser?: UserInfo;
|
||||
// Captured at app boot so access predicates can gate GPU Service —
|
||||
// the feature is Kubernetes-only, and Org members without a K8s
|
||||
// cluster they can schedule on shouldn't see the menu. Refreshed
|
||||
// by full page reload (e.g. OrgSwitcher) which re-runs
|
||||
// getInitialState.
|
||||
hasKubernetesCluster?: boolean;
|
||||
}
|
||||
|
||||
type SearchParams = Pagination & { search?: string; [key: string]: any };
|
||||
|
||||
Reference in New Issue
Block a user