livepeer / livepeer/go-livepeer

Move the AI worker from docker/docker to the moby/moby client

Open
#4,059 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

status: triage
Dominant language
Go
Stars
586
Forks
226
Avg merge
1d 17h
Merged PRs (30d)
19

Description

The last 5 open Dependabot alerts are on github.com/docker/docker and github.com/docker/cli, three high and two medium. No version bump closes them: the Docker Go module moved to github.com/moby/moby/client and github.com/moby/moby/api after 28.x, and docker/cli 29 only builds against those. Part of #4051.

Exposure today: none. go list -deps ./cmd/livepeer links only docker/client, docker/api/types/*, errdefs, pkg/jsonmessage and cli/opts. No daemon package and no CLI plugin loader is compiled in, and the copy and archive client APIs the alerts describe are never called anywhere in the repo. All five bugs live in code we do not ship.

Scope. ai/worker/docker.go and its test. The worker uses Docker through a local DockerClient interface with eight methods: ContainerCreate, ContainerInspect, ContainerList, ContainerRemove, ContainerStart, ContainerStop, ImageInspectWithRaw, ImagePull. Around thirty type uses across eleven imports.

Work

  1. Land after #4036, which trims the same files.
  2. Add the moby client and api modules at the versions docker/cli 29 vendors, bump docker/cli to 29, drop docker/docker and go-connections if nothing else needs them.
  3. Rewrite imports and renamed types, check the eight calls against the moby signatures, update the mock.
  4. Remove the docker/cli ignore from .github/dependabot.yaml.
  5. Verify on a GPU orchestrator end to end: pull, create with GPU devices and mounts, start, health check, stop, remove.

Risk of doing it. Contained to AI runner container management; failures are loud, not subtle. Same Docker API over the same socket, so no operator Docker upgrade. Ship with a canary orchestrator, not as a hotfix.

Risk of not doing it.

  • The daemon bugs are real on an orchestrator's host, but they are fixed by the operator's Docker installation, not by our go.mod. Bumping the module would protect nobody.
  • If code is later added that calls the copy or archive APIs, or the CLI plugin loader, the exposure becomes real and nothing re-flags it, because the alerts are already known-open.
  • Five permanently open alerts, three of them high, erode attention on the security page.

@j0sh Meaning it might not even be worth it if we deprecate the software for a more minimal modular stack soon.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with ai/worker/docker.go, its test, and go.mod; compare the eight DockerClient methods and current imports with the moby modules used by docker/cli 29. Done means the mock and calls build against moby, Dependabot no longer ignores docker/cli, and a GPU orchestrator completes pull, create, start, health check, stop, and remove.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, go
Domain
devops, infrastructure
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.