delete published rpms from the cache #2133
Conversation
| @@ -9,3 +9,5 @@ | |||
|
|
|||
| # Publish the repo - stderr/out redirect is required to stop the noninteractive shell from hanging | |||
| rsync --recursive --times --verbose --one-file-system --delete-after <%= @home %>/rsync_cache/$PROJECT/$RELEASE <%= @yum_directory %>/$PROJECT/ 2>&1 >/dev/null ; | |||
| # Cleanup - no need to keep the rpms | |||
| find <%= @home %>/rsync_cache/$PROJECT/$RELEASE -iname '*.rpm' -delete || true | |||
There was a problem hiding this comment.
this is taken from the Debian cleanup. technically we could also yank the whole folder here with an rm -rf, what's you preference?
There was a problem hiding this comment.
I would have thought we do not delete the cache so that we do not have to re-sync things that have already been synced and saved time and cost.
There was a problem hiding this comment.
Well, today I had to delete things to be able to upload new things.
Like, there was a full 3.9 that we never will publish again in the cache.
There was a problem hiding this comment.
Should it become part of retiring a release? Make it part of a procedure?
There was a problem hiding this comment.
It certainly could, even tho I don't like that too much as such things tend to get forgotten.
|
A Cron job that cleans up caches that are more than a certain age? Like a
month? Or are not in the current supported release list?
…On Fri, Sep 20, 2024, 2:21 PM Evgeni Golov ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In puppet/modules/web/templates/deploy-stagingyum.sh.erb
<#2133 (comment)>
:
> @@ -9,3 +9,5 @@
# Publish the repo - stderr/out redirect is required to stop the noninteractive shell from hanging
rsync --recursive --times --verbose --one-file-system --delete-after <%= @home %>/rsync_cache/$PROJECT/$RELEASE <%= @yum_directory %>/$PROJECT/ 2>&1 >/dev/null ;
+ # Cleanup - no need to keep the rpms
+ find <%= @home %>/rsync_cache/$PROJECT/$RELEASE -iname '*.rpm' -delete || true
It certainly could, even tho I don't like that too much as such things
tend to get forgotten.
—
Reply to this email directly, view it on GitHub
<#2133 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACHT42YWZX56QARUYRZXBLZXRRSFAVCNFSM6AAAAABORROY5OVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGMJYHE4DCOJXGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Could we use |
|
Today the cache and the repos are on different partitions, so hardlinks wouldn't work. But we could change that. Cronjob is probably easier? |
|
I'd like to change that since it's less IO, making it faster |
|
Getting back to this: I think we should use hardlinks (which implies moving over the cache location, but already makes it much faster). Then the cache essentially becomes free because we never delete production RPMs. However, we don't want to modify any release RPM so we need to be careful that rsync to the cache never modifies files. Then when we retire a release we should clean up the cache for it. |
No description provided.