3 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	b2f4dde288	fix(ansible): the swarm prune never runs a docker prune that touches images; it lives in its own folder (#6399) ... The first applied run lost VDNT-Docker03 29 images (10.4 GB) before its script ran. Its `docker system prune` removes dangling images, and Docker counts an image with no tag as dangling: every image a swarm task pulled by digest. Docker03 was left holding only its own tasks' images, as under the old prune. Nothing went down, since a running container's image can't be removed. - Step 1 now prunes containers, networks, build cache and (prune_volumes) volumes one by one. Every image decision is left to the script, which keeps the images services are pinned to. - A test guards against any image-pruning command in the playbook. - The playbook moves to maintenance/swarm_prune/, with its script in that folder's files/, so a helper's name can't collide with another playbook's (the operator's direction for playbooks with helpers). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-25 11:22:41 -04:00
bvandeusenandClaude Opus 5.5	b40e672cda	fix(ansible): the swarm prune reads every image from Docker's API, untagged ones included (#6399) ... `docker image ls` on Docker 29 leaves out images with no tag, which is every image a swarm task pulled by digest: the check run on VDNT-Docker03 saw 4 of its 58. Missing them only kept them, but superseded digests there would never have gone. The list now comes from GET /images/json on the socket. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-25 11:15:10 -04:00
bvandeusenandClaude Opus 5.5	6f0903f548	feat(ansible): a swarm prune that keeps every image a swarm service is pinned to on every node (#6399) ... The nightly prune ran `docker system prune -a`, which deletes every image no local container uses, so each swarm node kept only its own tasks' images. When the other node failed or was drained, its services had to pull first: on 2026-10-25 Traefik took 11.5 min to start on Docker03. maintenance/swarm_prune.yml (built in) prunes stopped containers, unused networks, dangling images and build cache, then removes only the images that no container uses and no swarm service is pinned to, wherever that service runs. Old digests left by redeploys still go. - A container's image is kept by its id and by the reference it was made from, since on the containerd store the id alone hasn't held a tag. - A node that can't list the swarm's services removes no images and fails rather than pruning blind. - Check mode lists what would go. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-25 11:08:37 -04:00