Remove 10 stale stopped containers wasting disk space and cluttering config #76

New Issue
Closed
opened 2026-07-13 00:37:23 +02:00 by retoor · 5 comments
retoor commented 2026-07-13 00:37:23 +02:00
Owner
Copy Link

Summary

The container service shows 22 total instances: 12 running, 10 stopped. The stopped containers are mostly from a cleanup/testing session and have no reason to exist anymore. They consume disk space, clutter the container list, and add overhead to the reconciliation loop.

Steps to Reproduce

  1. Observe the container service listing.
  2. Note 22 total instances: 12 running, 10 stopped.
  3. Identify the following stopped containers: rimg-request, xmlrpc-loadtest, cleanup-v2, xml-cleanup, xml-cleanup2, xml-mass-delete, xml-purge, xml-final-cleanup.

Expected Behaviour

Stopped containers that have completed their purpose should be removed to free disk space, reduce config clutter, and eliminate unnecessary reconciliation overhead.

Actual Behaviour

10 stopped containers remain, consuming 160.8 MB of disk space, cluttering the container list with 8+ dead entries, and adding overhead to the reconciliation loop.

Environment

Not provided.

Reported by retoor via DevPlace.

## Summary The container service shows 22 total instances: 12 running, 10 stopped. The stopped containers are mostly from a cleanup/testing session and have no reason to exist anymore. They consume disk space, clutter the container list, and add overhead to the reconciliation loop. ## Steps to Reproduce 1. Observe the container service listing. 2. Note 22 total instances: 12 running, 10 stopped. 3. Identify the following stopped containers: `rimg-request`, `xmlrpc-loadtest`, `cleanup-v2`, `xml-cleanup`, `xml-cleanup2`, `xml-mass-delete`, `xml-purge`, `xml-final-cleanup`. ## Expected Behaviour Stopped containers that have completed their purpose should be removed to free disk space, reduce config clutter, and eliminate unnecessary reconciliation overhead. ## Actual Behaviour 10 stopped containers remain, consuming 160.8 MB of disk space, cluttering the container list with 8+ dead entries, and adding overhead to the reconciliation loop. ## Environment Not provided. --- *Reported by **retoor** via DevPlace.*
plan-ticket-76.md
4.6 KiB
plan-ticket-76.md
2.2 KiB
plan-ticket-76.md
4.3 KiB
typosaurus commented 2026-07-19 23:48:55 +02:00
Collaborator
Copy Link

I am picking this ticket up now.

First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.

I am picking this ticket up now. First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
typosaurus commented 2026-07-19 23:49:05 +02:00
Collaborator
Copy Link

Starting research round 1 of at most 5.

I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.

Starting research round 1 of at most 5. I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
typosaurus commented 2026-07-19 23:51:12 +02:00
Collaborator
Copy Link

The ticket reports that ten stale stopped containers need to be removed. Reviewing the current source and tests confirms that the CLI command devplace containers prune-stopped already exists and performs exactly this cleanup. No code change is necessary to address the operational request; simply running the existing command resolves the issue.

This means the ticket does not describe a missing feature or bug. Could you confirm whether this assessment still matches the intended work, or should the ticket be closed as implemented?

The ticket reports that ten stale stopped containers need to be removed. Reviewing the current source and tests confirms that the CLI command `devplace containers prune-stopped` already exists and performs exactly this cleanup. No code change is necessary to address the operational request; simply running the existing command resolves the issue. This means the ticket does not describe a missing feature or bug. Could you confirm whether this assessment still matches the intended work, or should the ticket be closed as implemented?
retoor commented 2026-07-19 23:52:58 +02:00
Author
Owner
Copy Link

wtf:PNice,yea close!!!

Posted by retoor via DevPlace.

wtf:PNice,yea close!!! --- *Posted by **retoor** via DevPlace.*
typosaurus commented 2026-07-19 23:54:05 +02:00
Collaborator
Copy Link

This ticket has been cancelled and closed at your request. No implementation work was executed, as no rounds of execution or infrastructure retries were performed. The decision to cancel was made based on the direction provided. No further action is pending.

This ticket has been cancelled and closed at your request. No implementation work was executed, as no rounds of execution or infrastructure retries were performed. The decision to cancel was made based on the direction provided. No further action is pending.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: retoor/devplacepy#76
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?