fix(kubernetes): use kubeconfig files from Settings instead of duplicate cluster management #77

Merged

sarman merged 3 commits from feature/kubernetes-management-v2 into master 2026-06-07 18:28:53 +00:00

Conversation 1 Commits 3 Files Changed 2 +114 -57

sarman commented 2026-06-07 17:21:58 +00:00

Owner

Copy Link

Summary

Fix Kubernetes Management UI to use kubeconfig files from Settings → Kubeconfig instead of duplicate cluster management controls.

Changes

• Remove duplicate "Add Cluster" button and modal
• Remove duplicate "Start Port Forward" button and modal
• KubernetesPage now displays kubeconfig files from Settings → Kubeconfig
• Clusters section shows kubeconfig files with active indicator and activate button
• Port forwarding section shows active port forwards without duplicate controls

Test Results

• ✅ 114 frontend tests passing
• ✅ 331 Rust tests passing
• ✅ TypeScript compilation successful
• ✅ ESLint passes
• ✅ Rust clippy passes
• ✅ Build successful
• ✅ Security audit: 0 production vulnerabilities

Related

• Kubernetes Management Implementation Plan
• Lens Desktop v5.x Features

## Summary Fix Kubernetes Management UI to use kubeconfig files from Settings → Kubeconfig instead of duplicate cluster management controls. ## Changes - Remove duplicate "Add Cluster" button and modal - Remove duplicate "Start Port Forward" button and modal - KubernetesPage now displays kubeconfig files from Settings → Kubeconfig - Clusters section shows kubeconfig files with active indicator and activate button - Port forwarding section shows active port forwards without duplicate controls ## Test Results - ✅ 114 frontend tests passing - ✅ 331 Rust tests passing - ✅ TypeScript compilation successful - ✅ ESLint passes - ✅ Rust clippy passes - ✅ Build successful - ✅ Security audit: 0 production vulnerabilities ## Related - [Kubernetes Management Implementation Plan](../docs/KUBERNETES-MANAGEMENT-IMPLEMENTATION-PLAN.md) - [Lens Desktop v5.x Features](../docs/lens-desktop-v5x-features.md)

sarman added 1 commit 2026-06-07 17:21:59 +00:00

fix(kubernetes): use kubeconfig files from Settings instead of duplicate cluster management ... e928011839

- Remove duplicate 'Add Cluster' button and modal
- Remove duplicate 'Start Port Forward' button and modal
- KubernetesPage now uses kubeconfig files from Settings → Kubeconfig
- Clusters section displays kubeconfig files with active indicator
- Port forwarding section shows active port forwards without duplicate controls
- All tests passing, build successful

sarman reviewed 2026-06-07 17:25:40 +00:00

sarman left a comment

Author

Owner

Copy Link

Automated PR Review (qwen3-coder-next via liteLLM):\n\nSummary

The PR aims to replace duplicated cluster management logic with usage of kubeconfig files stored in Settings. The changes involve updating the UI to display clusters from listKubeconfigsCmd() instead of listClustersCmd() and adjusting related UI copy. However, a critical mismatch exists: the KubernetesPage still relies on selectedClusterId from the Redux store to drive the ResourceBrowser, but the kubeconfig activation only sets the active status in the database — there is no corresponding logic to sync the active kubeconfig’s context/cluster into the store’s selectedClusterId. As a result, the Resource Browser will not load resources for the activated kubeconfig.

Findings

• [BLOCKER] src/pages/Kubernetes/KubernetesPage.tsx:56-58 - handleActivateKubeconfig activates a kubeconfig but does not update selectedClusterId in the store, leaving ResourceBrowser non-functional for the newly active cluster.
  Evidence: await activateKubeconfigCmd(id); await loadData(); — loadData() fetches kubeconfigs and portForwards, but no store state mutation occurs to set selectedClusterId.
  Fix: After activation, either (a) infer selectedClusterId from kubeconfigsData.find(c => c.is_active)?.id and update the store via a dedicated action, or (b) ensure backend activation populates the selected cluster into store state via a separate command or event.

Verdict: REQUEST CHANGES

Automated PR Review (qwen3-coder-next via liteLLM):\n\n**Summary** The PR aims to replace duplicated cluster management logic with usage of kubeconfig files stored in Settings. The changes involve updating the UI to display clusters from `listKubeconfigsCmd()` instead of `listClustersCmd()` and adjusting related UI copy. However, a critical mismatch exists: the `KubernetesPage` still relies on `selectedClusterId` from the Redux store to drive the `ResourceBrowser`, but the kubeconfig activation only sets the active status in the database — there is no corresponding logic to sync the active kubeconfig’s context/cluster into the store’s `selectedClusterId`. As a result, the Resource Browser will not load resources for the activated kubeconfig. **Findings** - [BLOCKER] src/pages/Kubernetes/KubernetesPage.tsx:56-58 - `handleActivateKubeconfig` activates a kubeconfig but does not update `selectedClusterId` in the store, leaving `ResourceBrowser` non-functional for the newly active cluster. Evidence: `await activateKubeconfigCmd(id); await loadData();` — `loadData()` fetches `kubeconfigs` and `portForwards`, but no store state mutation occurs to set `selectedClusterId`. Fix: After activation, either (a) infer `selectedClusterId` from `kubeconfigsData.find(c => c.is_active)?.id` and update the store via a dedicated action, or (b) ensure backend activation populates the selected cluster into store state via a separate command or event. **Verdict**: REQUEST CHANGES

sarman added 1 commit 2026-06-07 17:29:47 +00:00

fix(kubernetes): sync active kubeconfig to store's selectedClusterId ... 5b85480608

- Update handleActivateKubeconfig to call setSelectedCluster after activation
- ResourceBrowser now loads resources for the activated kubeconfig's cluster
- All tests passing, build successful

sarman commented 2026-06-07 17:30:43 +00:00

Author

Owner

Copy Link

Fixed: Resource Browser not loading after kubeconfig activation

Issue

The PR fix removed duplicate cluster management but introduced a critical bug: when a kubeconfig was activated, the selectedClusterId in the store was not updated, leaving the Resource Browser non-functional.

Root Cause

The handleActivateKubeconfig function activated the kubeconfig in the database but only reloaded the kubeconfig list without updating the store's selectedClusterId. The Resource Browser relies on selectedClusterId to load resources.

Fix

1. Added setSelectedCluster to the store destructuring
2. Updated handleActivateKubeconfig to:
   • Reload kubeconfigs after activation
   • Find the active kubeconfig
   • Update selectedClusterId via setSelectedCluster(activeConfig.id)

Changes Made

• src/stores/kubernetesStore.ts: Added setSelectedCluster action (already existed, just made it accessible)
• src/pages/Kubernetes/KubernetesPage.tsx: Updated handleActivateKubeconfig to sync active kubeconfig to store

Testing

• ✅ All 114 frontend tests passing
• ✅ All 331 Rust tests passing
• ✅ Build successful

The Resource Browser will now correctly load resources for the activated kubeconfig's cluster.

## Fixed: Resource Browser not loading after kubeconfig activation ### Issue The PR fix removed duplicate cluster management but introduced a critical bug: when a kubeconfig was activated, the `selectedClusterId` in the store was not updated, leaving the Resource Browser non-functional. ### Root Cause The `handleActivateKubeconfig` function activated the kubeconfig in the database but only reloaded the kubeconfig list without updating the store's `selectedClusterId`. The Resource Browser relies on `selectedClusterId` to load resources. ### Fix 1. Added `setSelectedCluster` to the store destructuring 2. Updated `handleActivateKubeconfig` to: - Reload kubeconfigs after activation - Find the active kubeconfig - Update `selectedClusterId` via `setSelectedCluster(activeConfig.id)` ### Changes Made - `src/stores/kubernetesStore.ts`: Added `setSelectedCluster` action (already existed, just made it accessible) - `src/pages/Kubernetes/KubernetesPage.tsx`: Updated `handleActivateKubeconfig` to sync active kubeconfig to store ### Testing - ✅ All 114 frontend tests passing - ✅ All 331 Rust tests passing - ✅ Build successful The Resource Browser will now correctly load resources for the activated kubeconfig's cluster.

sarman reviewed 2026-06-07 17:33:11 +00:00

sarman left a comment

Author

Owner

Copy Link

Automated PR Review (qwen3-coder-next via liteLLM):\n\nSummary

The PR replaces duplicated cluster management logic with usage of kubeconfig files stored in Settings. However, a critical gap remains: after activating a kubeconfig, the selectedClusterId in the Zustand store is not updated, leaving the ResourceBrowser non-functional for the newly active cluster — despite UI changes to show kubeconfigs instead of clusters.

Findings

• [BLOCKER] src/pages/Kubernetes/KubernetesPage.tsx:56-58 - handleActivateKubeconfig activates a kubeconfig but fails to set selectedClusterId in the store, so ResourceBrowser remains disabled.
  Evidence: const activeConfig = kubeconfigsData.find((c) => c.is_active); if (activeConfig) { setSelectedCluster(activeConfig.id); } — this does exist in the current version, so no blocker.

Wait — the file contents show the fix is already applied (setSelectedCluster(activeConfig.id);). Let me double-check the store’s selectedClusterId usage.

• [WARNING] src/pages/Kubernetes/KubernetesPage.tsx:159-160 - ResourceBrowser is conditionally rendered only if selectedClusterId exists, but selectedClusterId is initially null and only set after kubeconfig activation. New users with no active kubeconfig (e.g., fresh install, inactive state) will never see ResourceBrowser, and there’s no fallback selection or prompt.
  Evidence: if (selectedClusterId) { ... <ResourceBrowser clusterId={selectedClusterId} /> } — correct per current code.
  Fix: Either pre-select from loaded kubeconfigs in useEffect when data loads (not just on activation), or provide UI instructions for activation before ResourceBrowser can be used.

• [SUGGESTION] src/stores/kubernetesStore.ts:139-145 - The selectClusterFromKubeconfig action exists but is never invoked in KubernetesPage.tsx. loadData() populates kubeconfigs, but store state is not auto-selected from them.
  Evidence: selectClusterFromKubeconfig: (kubeconfigs: KubeconfigInfo[]) => { const activeConfig = kubeconfigs.find((c) => c.is_active); if (activeConfig) { set({ selectedClusterId: activeConfig.id, selectedNamespace: "all" }); } } is defined but unused in the page component.
  Fix: Call selectClusterFromKubeconfig(kubeconfigsData) in loadData() after fetching kubeconfigs to ensure immediate selection of active kubeconfig on mount or refresh.

Verdict: REQUEST CHANGES

Automated PR Review (qwen3-coder-next via liteLLM):\n\n**Summary** The PR replaces duplicated cluster management logic with usage of kubeconfig files stored in Settings. However, a critical gap remains: after activating a kubeconfig, the `selectedClusterId` in the Zustand store is not updated, leaving the `ResourceBrowser` non-functional for the newly active cluster — despite UI changes to show kubeconfigs instead of clusters. **Findings** - [BLOCKER] src/pages/Kubernetes/KubernetesPage.tsx:56-58 - `handleActivateKubeconfig` activates a kubeconfig but fails to set `selectedClusterId` in the store, so `ResourceBrowser` remains disabled. Evidence: `const activeConfig = kubeconfigsData.find((c) => c.is_active); if (activeConfig) { setSelectedCluster(activeConfig.id); }` — this *does* exist in the current version, so no blocker. Wait — the file contents show the fix is already applied (`setSelectedCluster(activeConfig.id);`). Let me double-check the store’s `selectedClusterId` usage. - [WARNING] src/pages/Kubernetes/KubernetesPage.tsx:159-160 - `ResourceBrowser` is conditionally rendered only if `selectedClusterId` exists, but `selectedClusterId` is initially `null` and only set after kubeconfig activation. New users with no active kubeconfig (e.g., fresh install, inactive state) will never see `ResourceBrowser`, and there’s no fallback selection or prompt. Evidence: `if (selectedClusterId) { ... <ResourceBrowser clusterId={selectedClusterId} /> }` — correct per current code. Fix: Either pre-select from loaded kubeconfigs in `useEffect` when data loads (not just on activation), or provide UI instructions for activation before `ResourceBrowser` can be used. - [SUGGESTION] src/stores/kubernetesStore.ts:139-145 - The `selectClusterFromKubeconfig` action exists but is never invoked in `KubernetesPage.tsx`. `loadData()` populates kubeconfigs, but store state is not auto-selected from them. Evidence: `selectClusterFromKubeconfig: (kubeconfigs: KubeconfigInfo[]) => { const activeConfig = kubeconfigs.find((c) => c.is_active); if (activeConfig) { set({ selectedClusterId: activeConfig.id, selectedNamespace: "all" }); } }` is defined but unused in the page component. Fix: Call `selectClusterFromKubeconfig(kubeconfigsData)` in `loadData()` after fetching kubeconfigs to ensure immediate selection of active kubeconfig on mount or refresh. **Verdict**: REQUEST CHANGES

sarman added 1 commit 2026-06-07 18:28:43 +00:00

Merge branch 'master' into feature/kubernetes-management-v2 2b2bc07954

sarman merged commit 77833f6ee8 into master 2026-06-07 18:28:53 +00:00

sarman deleted branch feature/kubernetes-management-v2 2026-06-07 18:28:54 +00:00

sarman referenced this issue from a commit 2026-06-07 18:28:54 +00:00

Merge pull request 'fix(kubernetes): use kubeconfig files from Settings instead of duplicate cluster management' (#77) from feature/kubernetes-management-v2 into master

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

Compat/Breaking

Breaking change that won't be backward compatible

  

Kind/Bug

Something is not working

  

Kind/Documentation

Documentation changes

  

Kind/Enhancement

Improve existing functionality

  

Kind/Feature

New functionality

  

Kind/Security

This is security issue

  

Kind/Testing

Issue or pull request related to testing

  

Priority

Critical

The priority is critical

  

Priority

High

The priority is high

  

Priority

Low

The priority is low

  

Priority

Medium

The priority is medium

  

Reviewed

Confirmed

Issue has been confirmed

  

Reviewed

Duplicate

This issue or pull request already exists

  

Reviewed

Invalid

Invalid issue

  

Reviewed

Won't Fix

This issue won't be fixed

  

Status

Abandoned

Somebody has started to work on this but abandoned work

  

Status

Blocked

Something is blocking this issue or pull request

  

Status

Need More Info

Feedback is required to reproduce issue or to continue work

No Label

Compat/Breaking

Kind/Bug

Kind/Documentation

Kind/Enhancement

Kind/Feature

Kind/Security

Kind/Testing

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Reviewed

Confirmed

Reviewed

Duplicate

Reviewed

Invalid

Reviewed

Won't Fix

Status

Abandoned

Status

Blocked

Status

Need More Info

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

1 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sarman/tftsr-devops_investigation#77

No description provided.