Pause and resume the egress sidecar together with the sandbox in Docker runtime

[DigHuang]

Why do you need it?

OpenSandbox creates the egress component as a separate sidecar container，pauses the main sandbox container, but the egress sidecar remains running. This means:
The sandbox lifecycle state does not represent the complete sandbox data plane.
The egress sidecar continues consuming CPU and memory while the sandbox is paused.

Requirements

We would like sandbox.pause() and sandbox.resume() to manage the egress sidecar as part of the same lifecycle operation.

[luffy0x]

Hi, I'd like to work on this issue.
I traced the Docker runtime and found that the sandbox container shares the
egress sidecar's network namespace, while pause/resume currently only operates
on the sandbox container.
My proposed scope is:

• pause the sandbox container before the egress sidecar
• resume the egress sidecar before the sandbox container
• preserve existing behavior when no sidecar is configured
• add compensating rollback for partial failures
• add focused Docker service tests for ordering and failure cases
  Before I start, could you confirm:

1. Should resume fail closed when an expected egress sidecar is missing?
2. Is compensating rollback the expected behavior for partial failures?

[DigHuang]

Thanks for tracing this. Before deciding whether resume() should fail closed, could a missing egress sidecar be automatically recovered or recreated while preserving its network namespace and configuration?
Also, when you mention compensating rollback for partial failures, what specific rollback behavior do you have in mind? For example, if one container operation succeeds and the other fails, should we attempt to restore both containers to their original states?

[luffy0x]

@DigHuang Thanks for the questions. I checked the current Docker setup and reproduced the recovery cases locally. If the egress sidecar is only paused, the same container can be unpaused while preserving the shared network namespace. However, if it has exited, starting it again creates a new network namespace while the main container remains attached to the old one. If it has been deleted, a replacement can join the namespace retained by the main container, but Docker does not allow published ports with `network_mode=container:<main-id>`, and the main container still references the deleted sidecar ID. The complete network policy and egress configuration are also not persisted outside the sidecar today. Therefore, for #1441, I suggest automatically recovering only an existing paused sidecar, including resolving it from the main container's `HostConfig.NetworkMode` if label-based lookup is stale. For an exited or deleted sidecar, `resume()` should keep the main container paused and fail closed. Transparent recreation would require persisted sidecar state and probably a stable network namespace owner, which seems broader than #1422. By compensating rollback, I mean recording and re-inspecting both containers' states, then undoing only transitions made by the current operation while preserving the invariant that the main container must not run unless egress is confirmed running. During pause, if the sidecar step fails, we should first reconcile the sidecar back to Running. Only after confirming that should we unpause the main container; otherwise, the main container remains paused. During resume, we should unpause and verify the sidecar first. If unpausing the main container fails, we should re-inspect it and re-pause the sidecar only if the main container is confirmed Paused. If the main container is Running or its state is uncertain, the sidecar should remain Running. So the goal is to restore both containers to their original states when it is safe and verifiab

…

---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 发送日期 | 2026年08月04日 21:45 | | 收件人 | opensandbox-group/OpenSandbox ***@***.***> | | 抄送人 | Wang ***@***.***>, Comment ***@***.***> | | 主题 | Re: [opensandbox-group/OpenSandbox] Pause and resume the egress sidecar together with the sandbox in Docker runtime (Issue #1422) | DigHuang left a comment (opensandbox-group/OpenSandbox#1422) Thanks for tracing this. Before deciding whether resume() should fail closed, could a missing egress sidecar be automatically recovered or recreated while preserving its network namespace and configuration? Also, when you mention compensating rollback for partial failures, what specific rollback behavior do you have in mind? For example, if one container operation succeeds and the other fails, should we attempt to restore both containers to their original states? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>