Summary

What is the problem or use case, what are we trying to achieve?

When Docker or Podman is installed but its daemon isn't running, drivers-orchestration (run/start/stop) prints a raw Docker CLI error, an ERROR log line, and a full Python traceback instead of failing gracefully. We want to detect that the daemon is unreachable and handle it quietly.

Proposed fix: gist plan

Motivation

Who is the affected end user?

Driver engineers running local orchestration commands using .evergreen/orchestration, or as part of Evergreen scripts.

How does this affect the end user?

It's confusing and noisy; users see a scary traceback on a routine command even though the tool already handles "no docker" gracefully elsewhere. I have seen Claude get confused by it as well, thinking it was the source of an error that actually occurred elsewhere.

How likely is it that this problem or use case will occur?

Common. Hit any time a developer has docker/podman installed but not currently running, and also observed on some Evergreen hosts where docker is running but not functioning correctly.

If the problem does occur, what are the consequences and how severe are they?

Minor — noisy/confusing output with no functional breakage in most cases. One related path (start --local-atlas) fails with an unrelated, confusing error instead of a clear one.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No — functional change to error handling/logging behavior, not test coverage.

Acceptance Criteria

What specific requirements must be met to consider the design phase complete?

• No raw Docker CLI text or traceback when the daemon is unreachable.
• No misleading ERROR-level output at default log level; detail available with -v.
• start --local-atlas gives one clear, actionable error when the daemon is unreachable.
• No regression when Docker/Podman is absent or running normally.