## [mirendev/runtime#1428](https://github.com/mirendev/runtime/pull/1428) I think this is ready for a human to look at. The upgrade-behavior concern I raised is gone, and the one thing left needs a person to sign off on the rollout, not a code change. **#1411 is out of the batch.** `controllers/sandboxpool/manager.go`, the `scaling.md` warning and the #1411 changelog entry are all gone from this layer's diff. `checkPoolForScaleDown` still skips sandboxes with a zero `LastActivity` (`manager.go:698-699`), so long-running TCP/UDP-only services keep their current behavior on upgrade. Holding it for the next minor resolves the concern, and I've closed that thread. **Sandboxpool tests.** The description now covers `controllers/sandboxpool` on the combined tree. You report one failure, `TestManagerLongStartupFailureBackoff`, which you say fails the same way on plain v0.17.2. I haven't run it myself, and with #1411 gone this layer doesn't touch that package anyway. **The release commit.** `5a90252` and `154027e` only change the changelog. The #1387 entry from #1427 now sits under `## v0.17.3` with the three entries for this batch. **What a human should check before tagging: the containerd rollout on hosts that already have leftover daemons (eu1, by your note).** Two outcomes are possible: - **The leftover daemons match.** `findSurvivors` only treats a process as ours if its `--address` equals our socket path and its `--config` points at the same file as `/containerd/config.toml`. The match is by identity, and that works because `generateDefaultConfig` rewrites the file in place, so the inode stays the same. Matching daemons get SIGTERM, then SIGKILL after 30s, and the containerd version changes on that restart. That's the outcome the changelog describes. - **A leftover daemon doesn't match.** For example, it was started with a different `--config` path. Then it isn't stopped. Our new daemon blocks on the bolt lock, `waitForSocket` connects to the old daemon, and `checkSocketOwner` fails (`containerd.go:247-258`). So the server **fails to boot**, where before it limped along on the old daemon. Failing fast is what #1416 intends, but for that host it means an outage instead of a silent degradation. Before upgrading eu1, it's worth checking `/proc//cmdline` on its stray containerd processes to confirm they were started with `--address /containerd/containerd.sock --config /containerd/config.toml`. The merge order is the same as before: wait for #1427, retarget to `release/0.17`, then merge with a merge commit. I'm not recommending that this skip human review. It's a release cut that kills processes on production hosts, and someone who knows those hosts should sign off on the rollout. ## Inline comments - **components/containerd/containerd.go:249** — I'm flagging this for a human to check on the affected hosts. It isn't a defect. If a stray containerd on this socket isn't matched by `findSurvivors`, for example because it was launched with a different `--config` path, it's never stopped. Our new daemon then blocks on its bolt lock, `waitForSocket` succeeds against the stray one, and this check fails Start. The server then refuses to boot, where before this change it ran on the stray daemon. That's the intended fail-fast, but before rolling v0.17.3 onto eu1 someone should confirm its leftover daemons' cmdlines carry `--address /containerd/containerd.sock --config /containerd/config.toml`, so they're cleaned up instead of blocking boot. ## Replies to existing threads _Posted to the PR's comment threads when you submit._ - _(reply & resolve: addressed)_ Thanks, I agree this belongs in a minor rather than a patch. In this layer, `manager.go` and `scaling.md` are no longer changed, the #1411 changelog entry is gone, and zero-`LastActivity` sandboxes are still skipped in `checkPoolForScaleDown`. Existing services won't start scaling down on upgrade, so I'm closing this. --- **Verdict:** ready