Proposal: Dynamic Network Discovery via Kubernetes API & Standardized Labeling

Problem

The frontend currently relies on static environment variables to connect to network clients, limiting flexibility. A previous proposal suggested a static registry file, but that introduces synchronization overhead.

Proposed Solution

Enable the frontend to dynamically discover deployed networks by directly querying the Kubernetes API. This leverages the cluster's source of truth and allows for real-time status monitoring (e.g., detecting 'Provisioning' or 'Error' states).

1. Standardized Labeling & Naming

To support this, we must enforce a strict naming and labeling convention across the stack (CLI and Helm charts).

Naming Convention: <chain>.<network>.<uid> (e.g., ethereum.hoodi.whatever-pet-name) for namespaces or release names to avoid collisions.

Required Labels (on Services/Pods):

• app.kubernetes.io/part-of: obol.stack (Primary filter)
• obol.stack/chain: <chain> (e.g., ethereum, aztec)
• obol.stack/network: <network> (e.g., mainnet, hoodi, sepolia)
• obol.stack/type: <type> (e.g., execution, consensus, sequencer)
• obol.stack/client: <client> (e.g., reth, lighthouse)

2. Component Changes

Stack (Helm Charts & CLI)

• Update Helm Charts: Ensure all deployed resources (Services, StatefulSets) automatically apply these standard labels based on the input values.
• Update CLI: Ensure the deployment process sets these values correctly.

Frontend (obol-stack-front-end)

• RBAC: Ensure the obol-frontend ServiceAccount has list and get permissions for services and pods in the relevant namespaces (or cluster-wide if applicable).
• KubernetesAPIClient:
  • Implement K8s API calls to /api/v1/services and /api/v1/pods.
  • Filter results using labelSelector=app.kubernetes.io/part-of=obol-stack.
  • Group discovered services by chain and stac to construct the dashboard view.
  • Extract status from Pod conditions to show real-time health (e.g., 'ContainerCreating', 'CrashLoopBackOff').

Benefits

• Real-Time Accuracy: The dashboard reflects the exact state of the cluster.
• Rich Status: Users can see if a node is syncing, starting up, or failed, directly from the UI.
• Zero-Config: No registry file to maintain; deployment is registration.

Start by mapping the Helm charts and CLI deployment path, then inspect the frontend KubernetesAPIClient entry point and RBAC configuration. Done means standardized labels are applied, permissions allow service and pod discovery, and the dashboard groups resources and reports pod health through the specified Kubernetes API endpoints.