bridge

Problem removes a source Deployment's labels so that existing Services don't select the bridge pod. It keeps any label a env var reads (). A common pattern is a pod that reads its service name from , with its Service selecting on that same label. A proxy bridge of such a Deployment keeps the label and joins the real Service's endpoints. Once the bridge's device is gone, the Service sends a share of its traffic to the bridge pod, and those requests fail with 502s or hang. Solution Before stripping, replaces each downward-API label env var with the label's value, in both containers and init containers. It resolves values the way the downward API would, so an absent label becomes . Since nothing reads the labels any more, all source labels are stripped, and the bridge's own labels are injected as before. The pod's env is unchanged. Tests (new): a pod reads from . The test checks that the Service's selector no longer matches the bridge pod and that is inlined. It fails without this change. and now assert that the values are inlined and the labels stripped. Bridges that already exist keep their labels until they're recreated or deleted. 🤖 Generated with Claude Code

named the CA secret , and only appends the device ID, so every bridge from one machine shared : Each create replaced the others' CA. generates a new CA per create and upserts it over the shared secret. Concurrent creates raced. Both found it missing and created it, so the second failed with . That's what broke the managed-drives e2e when it brought two bridges up at once. One remove deleted it for everyone.** Each create relabels the secret with its own , so removing whichever bridge created it last deletes it. The device's other bridges keep running, but their pods can't restart, because the secret volume is gone. I hit this in venus: removing a test bridge deleted , which three live bridges still mount. Change The secret is named after the bridge, , so it carries only its own bridge's labels and deletes only that one. Nothing else refers to the secret by name. The proxy reads the CA from its mount, and the devcontainer gets it from the proxy's metadata. Rollout Existing bridges keep mounting the old shared secret until they're recreated. New bridges never touch it. A shared secret that's already been deleted only matters if a bridge pod restarts. Recreating that bridge fixes it. Testing runs , , and for two bridges from one device. It checks that each gets its own secret, labeled with its own bridge's deployment and mounted by it. Without the fix, both bridges get . , and pass. 🤖 Generated with Claude Code

Bridging from source manifests () copied every resource in them, including the service's HorizontalPodAutoscaler and PodDisruptionBudget. The transforms rename those copies, but they still act on the source workload: an HPA's and a PDB's selector name the real Deployment and its pods. So every bridge broke the real service while it existed: the real HPA reported and stopped scaling (venus's is in this state now) pods covered by more than one PDB can't be evicted ( events on venus's pods) Change runs a new transform first, which drops HPAs, PDBs and KEDA ScaledObjects from the bundle. A bridge is a single pod with nothing to scale. only ever copies the Deployment, so only bridges were affected. #12 already deletes any that existing bridges created, on . Rollout Venus's administrator has been running since 2026-07-02, before #12, so there still leaves these behind. There are 1,041 HPAs and 1,635 PDBs from bridges that no longer exist. It runs with , so restarting it picks up #12, #15 and this. The existing orphans need a one-time cleanup, since their bridges are gone and nothing will call remove for them. Testing : a packed source with a Deployment, Service, HPA, PDB and ScaledObject parses to five resources, and only the Deployment and Service survive the transform. , and pass. 🤖 Generated with Claude Code