-
Notifications
You must be signed in to change notification settings - Fork 96
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
Replacing or dropping publish_distro #2954
Comments
Otherwise this is a low prio item |
publish_log_setx.log rsync: [generator] failed to hard-link /srv/ftp-stage/pub/opensuse//distribution/leap/15.5/appliances/openSUSE-Leap-15.5-ARM-E20-efi.aarch64.raw.xz with openSUSE-Leap-15.5-ARM-E20-efi.aarch64.raw.xz: Invalid cross-device link (18) |
In general it is still good to delay deletion of old files for some hours in case users do So overall, we could even use 3 phases for distribution packages (so not /repositories):
|
FYI, I am investigating options for combined solution covering/integrating publish_distro, repopusher and tumbleweed-snapshot. Maybe MirrorCache integration as well. Have some ideas atm, but not sure how it will look like. So in case of any ideas or status check - let me know. |
Hello team,
publish_distro seems to have a simple job of rsyncing one directory to another (ftp-stage to ftp-prod), with a delay of n-hours, and there is a cleanup mechanism to keep older copies of files for n-days. I guess the first comes handy to ensure that all data is written/synced to ftp-stage by obs publisher, and the latter comes in handy so people don't get their repodata constantly invalidated during the development cycle.
However, we do see weird anomalies when appliances for the released version of Leap 15.X are not refreshed for months and simply calling the script with --force fixes it.
Configuration is doubtful (regexes that don't have much use in the current logic) etc. And overall the script tries to be to smarty-pants for what it's supposed to do.
The part for mirror brain was disabled in favor of mirror cache which we don't have to worry about.
publish.log
Could we have a simpler replacement and do we need it at all?
The text was updated successfully, but these errors were encountered: