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.

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

Allow running the script one time #290

Closed
wants to merge 4 commits into from
Closed

Conversation

c99a
Copy link

@c99a c99a commented Feb 27, 2024

We have been using docuum for more than a year now and we are trying to optimize and avoid job errors like missing docker layers. This can happen rarely when docuum starts to remove some layers and the current gitlab job is trying to use the docker image needing that layer ( at least that's my interpretation ).
Thus we are switching to a per runner maintenance mode that runs all the cleanups only on demand so the docuum nssm service would interfere.
Maybe this is useful for others too.
Best Regards,
Costin

Status: Ready

@stepchowfun
Copy link
Owner

Hi @c99a, thank you for your pull request!

However, if I understand your plan, you are giving up the main benefit of Docuum: collecting image usage data to be used for deciding which images to delete (least recently used). Docuum can't listen for Docker events when it isn't running.

If Docuum doesn't have any information about the image usage history, it will fall back to the image creation date to decide which images to delete, which is not very different from using docker image prune with a timestamp. The main remaining difference is that Docuum will delete images until a specified disk usage threshold is met, whereas Docker's built in pruning commands will only accept a timestamp cutoff.

So, I am a bit hesitant to accept this pull request, since it seems to be a bit misleading about what is actually happening.

@c99a
Copy link
Author

c99a commented Feb 27, 2024

Hi @stepchowfun.
I see, I didn't fully read the algorithm, just assumed that the vacuum function is somehow smart enough to parse the past docker events.
Then you're right, it doesn't make sense to add these changes.
Will it make sense to output the gathered docker events to a file then use that as input on a subsequent docuum run ?

@stepchowfun
Copy link
Owner

stepchowfun commented Feb 27, 2024

just assumed that the vacuum function is somehow smart enough to parse the past docker events.

Unfortunately Docker does not provide a way to read past events.

Will it make sense to output the gathered docker events to a file then use that as input on a subsequent docuum run ?

Docuum already saves the usage timestamps to a file while it's running (such that the information is not lost when the program restarts), so perhaps you just need a way to run Docuum in a mode that does not delete any images. Now that I think about it, this should already be possible with the current available options. Something like --keep '.*' or --threshold '1000000 GB' (pick a sufficiently large threshold). Can you see if one of those is sufficient for your use case?

@c99a
Copy link
Author

c99a commented Feb 27, 2024

That sounds great, I was also going to keep the deamon with a large threshold, then simply run the docuum with single run when the server maintenance window is triggered.
Thanks for clarifying.
So I can close the pull request ? I will simply put these changes on top of newer docuum code when needed.

@stepchowfun
Copy link
Owner

Yes, that sounds good. I'll close it for you. Thanks for the discussioin!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants