Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docker: Fix docker image gc tracking #7947

Merged
merged 1 commit into from
May 13, 2020
Merged

docker: Fix docker image gc tracking #7947

merged 1 commit into from
May 13, 2020

Conversation

notnoop
Copy link
Contributor

@notnoop notnoop commented May 13, 2020

This fixes a bug where docker images may not be GCed. The cause of the
bug is that we track the task using task.ID+task.Name on task start
but remove on plain task.ID.

This harmonize the two paths by using task.ID, as it's unique enough
and it's also used in the loadImage path (path when loading an image
from a local tarball instead of dockerhub).

Fixes #7940

@notnoop notnoop requested a review from nickethier May 13, 2020 15:23
@notnoop notnoop self-assigned this May 13, 2020
@notnoop notnoop mentioned this pull request May 13, 2020
Closed
nickethier
nickethier approved these changes May 13, 2020
View reviewed changes
Copy link
Member

@nickethier nickethier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any easy way to test this?

@benbuzbee
Copy link
Contributor

Thanks for being so fast! I will pull this patch into our environment today and see what happens.

I recommend adding a check similar to the log I added to debug it where it logs an error or warning if the callerID isnt found in the references map, in case this happens again or elsewhere

docker: Fix docker image gc tracking
72c08e0 
This fixes a bug where docker images may not be GCed.  The cause of the
bug is that we track the task using `task.ID+task.Name` on task start
but remove on plain `task.ID`.

This haromize the two paths by using `task.ID`, as it's unique enough
and it's also used in the `loadImage` path (path when loading an image
from a local tarball instead of dockerhub).
@notnoop
Copy link
Contributor Author

notnoop commented May 13, 2020 •
edited
Loading

Any easy way to test this?

Sadly, not trivially without depending on dockerhub (or an external registry), which our tests seem to try to avoid. The loading image path is tested well though...

@notnoop notnoop merged commit 71037b4 into master May 13, 2020
@notnoop notnoop deleted the b-docker-image-cleanup branch May 13, 2020 16:51
@notnoop notnoop mentioned this pull request May 27, 2020
Merged
@notnoop notnoop mentioned this pull request Jul 28, 2020
Closed
@github-actions
Copy link

github-actions bot commented Jan 6, 2023

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@nickethier nickethier nickethier approved these changes

@benbuzbee benbuzbee benbuzbee approved these changes

Assignees

@notnoop notnoop

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Docker driver leaks images
3 participants
@notnoop @benbuzbee @nickethier