Container Groups: recreate vs restart for VPN-sidecar dependents

[amayer1983]

Continuation of a thread in #2 with @famewolf.

Context

v1.17.0 added the restart_dependents flag on Container Groups. When the first ("head") container of a group is updated, all other members get a docker restart after the head reports healthy. Typical use: Gluetun head + Sonarr / Radarr / qBittorrent dependents sharing the namespace.

The open question

@famewolf reports that for Gluetun stacks specifically, restart of dependents is sometimes enough but sometimes not — particularly when Gluetun is recreated (= updated to a new image with a new container ID) rather than just restarted in place:

"if gluetun is recreated then a restart of dependents is not always sufficient. Sometimes it requires the containers to be actually rebuilt."

Plausibly because network_mode: "container:gluetun" can resolve by ID at container-start time, and the cached ID doesn't refresh on a plain restart.

What we could add

A second optional flag on Container Groups — something like recreate_dependents (one notch beyond restart_dependents). When set, dependents would stop + rm + docker run from inspect data (same logic we already use for the head's own update in update_checker._update_standalone).

Trade-off: recreate is more invasive, has more failure modes (volume locks, port conflicts during the gap), but actually re-resolves network_mode: container:<id>.

What I'd like to know

• @famewolf — your v1.17.0+ test results would directly inform this. Does restart alone work for your stack after the Gluetun fix, or do you still see dependents stuck?
• Anyone else running VPN-sidecar setups: how do you handle the "Gluetun got recreated" case manually today?

If restart turns out to be enough in practice for most stacks, recreate may not be worth the complexity. If it's regularly not enough, we ship it.