glm-5.2
ab963d0e46
Resolve the deferred docker system events subscription question. docker/system/events is now a v1 Subscription operation using the same StreamingHandler pattern already wired for logs, exec, and image/pull. The internal ownership-store subscription for stale-entry cleanup on destroy events is a follow-up refinement. Scrub hedging language from ADR-060 and docker specs: - Remove 'marginal gain' / 'future feature is additive' framing - Replace 'no reaper' / 'not promptly cleaned up' with clean statement that events subscription provides the prompt-cleanup path - Remove stale-entry policy from ADR-060's two-way door classification
1.5 KiB
1.5 KiB
OQ-50: Docker System Events Subscription
- Origin: crates/docker/docker-operations.md §"Operation Surface"; ADR-060 §4 (autonomous-death tolerance).
- Status: resolved
- Door type: Two-way
- Priority: low
- Resolution:
docker/system/eventsis included in v1 as aSubscriptionoperation. bollard'sevents()returnsStream<SystemEventsMessage>— the sameStreamingHandlerpattern already wired forlogs,exec, andimage/pull. The operation surfaces daemon events (container start/stop/die/destroy, image pull/tag/delete, etc.) ascall.respondedframes. The internal ownership-store subscription for stale-entry cleanup ondestroyevents is a follow-up refinement — the operation itself is the architecture decision. The use case is already documented in ADR-060 §4 (autonomous container death leaves stale ownership entries); the operation is cheap to add (same mechanicalStreamingHandlermapping as the three existing streaming ops) and generally useful beyond ownership cleanup (any consumer may want daemon events). - Cross-references: ADR-060 §4 (teardown coupling — stale-entry tolerance is the base model; the events subscription provides the prompt-cleanup path), crates/docker/docker-operations.md