Add cluster pre-open hooks + main-process proxy lifecycle

[yolossn]

Description

Core changes to support AKS Hybrid & Edge (Arc-connected) clusters, which connect through a local az connectedk8s proxy.

Two parts:

1. Proxy lifecycle (app layer, AKS-specific) — start, stop, and kill-on-quit for the az connectedk8s proxy processes, tracked per cluster.

2. Cluster pre-open hooks (upstreamable:) — a generic hook that runs before a cluster opens, which plugins can use to prepare a cluster: set up auth, refresh credentials, resume a stopped cluster, start a proxy, etc. The promise gates entry — pending shows a connecting popup, reject surfaces the error, resolve opens the cluster.

Why the app layer

The proxy lifecycle has to live in the app layer — the plugin can't drive it completely. az connectedk8s proxy (and its arcProxy child) is a long-lived process that must survive renderer reloads, stay stoppable by cluster afterwards, and be killed on app quit. The renderer loses its handle on reload and can't run teardown on quit, so only the main process can own start/stop/kill; the plugin just triggers it over IPC.

Testing

Test together with the plugin PR: #782. Test cases are already part of #782

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Performance improvement
• Code refactoring
• CI/CD changes
• Other: **___**

[Copilot]

Pull request overview

Adds a “cluster pre-open” extension point so plugins can asynchronously prepare a cluster (e.g., start an Arc proxy) before cluster views/auth checks run, and adds Electron main-process lifecycle management for az connectedk8s proxy so it can be started/stopped per cluster and killed on app quit.

Changes:

• Introduces ClusterPreOpenHook registration + Redux state to track “preparing” clusters and progress messages.
• Gates cluster route rendering/auth probing behind pre-open preparation, and suppresses the “Lost connection” banner during preparation.
• Adds main-process IPC + tracking to start/stop AKS Hybrid & Edge proxies per cluster and kill them on before-quit.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
frontend/src/redux/clusterProviderSlice.ts	Adds pre-open hook types + Redux state (preOpenHooks, preparing) and actions to track preparation.
frontend/src/plugin/registry.tsx	Exposes registerClusterProviderPreOpen for plugins to register pre-open hooks.
frontend/src/components/common/AlertNotification.tsx	Suppresses the “Lost connection” banner while the current cluster is preparing.
frontend/src/components/App/RouteSwitcher.tsx	Runs pre-open hooks before rendering cluster views / probing auth; shows a connecting dialog + progress.
frontend/src/components/App/Home/ClusterContextMenu.tsx	Ensures built-in Delete isn’t hidden just because plugins added menu items.
app/electron/runCmd.ts	Tracks proxy child processes per cluster; adds IPC to start/stop proxy; provides kill-on-quit utilities.
app/electron/preload.ts	Allows renderer to send the new start/stop proxy IPC messages.
app/electron/main.ts	Kills any running proxies on app before-quit.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.

[Copilot]

Pull request overview

Copilot reviewed 35 out of 35 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 35 out of 35 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 35 out of 35 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

frontend/src/redux/clusterProviderSlice.ts:52

• The JSDoc for clusterConf says it can be null, but the exported type is unknown (non-nullable). This makes hook authors handle a value the type system claims can’t happen, and can cause unnecessary narrowing/casts in plugins. Make the type reflect the documented nullability.

[Copilot]

Pull request overview

Copilot reviewed 35 out of 35 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

app/electron/runCmd.ts:143

• stopProxyForCluster schedules a new SIGKILL timeout and registers a new exit listener every time it’s called. If a user/plugin issues repeated Stop requests (double-click, retries), this can stack multiple timers/listeners for the same child process (eventually causing MaxListeners warnings and redundant signals). Consider making the delayed SIGKILL fallback idempotent per tracked proxy.

  const killTimer = setTimeout(() => {
    if (entry.child.exitCode === null && entry.child.signalCode === null) {
      signalChildEntry(entry, 'SIGKILL');
    }
  }, 4000);

[illume]

Some questions:

• who upstreams this into headlamp, and what happens then?
• Can we support this in headlamp without a plugin?
  • What about other proxies/tunnels? Maybe we can support ssh tunnels at the same time, and just leave this in headlamp.
• When we remove az command, what happens then?
  • there was some investigation into using APIs instead
• Did you think about in-cluster support?
• desktop API can be called by other plugins/code
  • consider scriptjs
• atomic commits, and commits messages need bodies
• The PR description doesn't describe, no testing instructions, and there's no link to issues/PRs etc
• new component states should have storybook states
• some of this AKS desktop proxy code in headlamp looks in the wrong place

[Copilot]

Pull request overview

Copilot reviewed 38 out of 38 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

frontend/src/redux/clusterProviderSlice.ts:53

• ClusterPreOpenContext.clusterConf is documented as "... or null if unavailable" and AuthRoute can pass null when it can’t find a config. Consider reflecting that in the exported type so hook authors know to handle the null case explicitly (instead of relying on unknown to implicitly include it).

[yolossn]

Some questions:

• who upstreams this into headlamp, and what happens then?

I can do it once the feature is merged, or it can also be part of the usual Headlamp ↔ aksd rebase.

• Can we support this in headlamp without a plugin?

If you mean the preOpen hook. Yes, it lives in core and any plugin can register against it; nothing about it is AKS-specific. Could you expand on the question a bit so I answer the right thing? Happy to go deeper if you meant something else.

• What about other proxies/tunnels? Maybe we can support ssh tunnels at the same time, and just leave this in headlamp.

Happy to keep the core lifecycle generic and drop the AKS-specific naming. But SSH/port-forward as first-class tunnels is a separate design, so I'd keep it out of scope here and do it as a follow-up if there's demand.

• When we remove az command, what happens then?
  there was some investigation into using APIs instead

Doing the proxy over the API instead of the az command isn't straightforward — it's a websocket relay, not a plain REST call. I've also been told the proxy is only an interim access mechanism on the Hybrid/Edge cluster side; they plan to move away from the proxy-command dependency themselves. So I've kept the transport decoupled from the lifecycle here, which means when that migration happens we swap the transport without reworking start/stop/kill.

• Did you think about in-cluster support?

Not possible by design. The approach relies on a machine-local az login and a local loopback proxy — in a shared/in-cluster deployment that would mean one user's credentials serving everyone and one user's proxy being reachable by others, i.e. a data leak. So it's desktop-only and single-user by nature.

• desktop API can be called by other plugins/code
  consider scriptjs

The scriptjs/pluginRunCommand pattern is fire-and-forget command execution — it works when the CLI owns its own lifecycle, i.e. start and stop are independent, stateless calls and the process daemonizes itself.

The Arc proxy is different. az connectedk8s proxy is a long-lived foreground process with no stop command — to stop it you have to kill the exact process you spawned (and its arcProxy child). So something persistent has to hold that process handle to stop it later or kill it on app quit. The renderer can't: it loses the handle on reload and can't run teardown on quit. That's why start/stop/kill lives in the app layer keyed by cluster

• atomic commits, and commits messages need bodies

The commits already has message bodies, broke down the commits into smaller ones.

• The PR description doesn't describe, no testing instructions, and there's no link to issues/PRs etc
  new component states should have storybook states

Added storybook wherever necessary and updated the PR description.

• some of this AKS desktop proxy code in headlamp looks in the wrong place

The proxy lifecycle has to live in the app layer — the plugin can't drive it completely. It's a long-lived OS process (az connectedk8s proxy + its arcProxy child) that must survive renderer reloads, stay stoppable by cluster afterwards, and be killed on app quit. The renderer loses its handle on reload and can't run teardown on quit, so only the main process can own start/stop/kill; the plugin just triggers it over IPC. Like the other AKS-specific commits already part of headlamp-downstream. The AKS specifics here are by design for the fork, not code meant to go upstream, so it's consistent with how we already scope AKS-specific changes. The pieces I did intend for upstream are split out and tagged as upstreamable

[Copilot]

Pull request overview

Copilot reviewed 41 out of 41 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

app/electron/runCmd.ts:140

• stopProxyForCluster can be called multiple times for the same tracked child (e.g. repeated IPC Stop events). Each call currently schedules a new SIGKILL fallback timer and adds another once('exit', ...) listener, which can lead to unnecessary timers/listener accumulation and repeated kill attempts.

Consider making Stop idempotent per tracked proxy by storing (and reusing) a single pending kill timer on the tracked entry, and returning early when a stop is already in progress.

  // Force-kill fallback a few seconds later, only if the child hasn't already
  // exited — avoids ESRCH noise and, more importantly, signalling a reused PID.
  // The timer is cancelled when the child exits (the common case after SIGTERM).
  const killTimer = setTimeout(() => {
    if (entry.child.exitCode === null && entry.child.signalCode === null) {