openSUSE / zypper

World's most powerful command line package manager
http://en.opensuse.org/Portal:Zypper
Other
403 stars 110 forks source link

Zypper doesn't show true mirror which has invalid content #478

Open Firstyear opened 1 year ago

Firstyear commented 1 year ago

It's very common in our github ci environment that zypper will randomly fail with:

#8 [linux/amd64 repos 2/2] RUN     --mount=type=cache,id=zypp,target=/var/cache/zypp     zypper mr -k repo-oss &&     zypper mr -k repo-non-oss &&     zypper mr -k repo-update &&     zypper dup -y
#0 0.109 RPM files caching has been enabled for repository 'repo-oss'.
#0 0.137 RPM files caching has been enabled for repository 'repo-non-oss'.
#0 0.180 RPM files caching has been enabled for repository 'repo-update'.
#0 1.442 Retrieving repository 'openSUSE-Tumbleweed-Non-Oss' metadata [.....error]
#0 3.357 Repository 'openSUSE-Tumbleweed-Non-Oss' is invalid.
#0 3.357 [repo-non-oss|http://download.opensuse.org/tumbleweed/repo/non-oss/] Valid metadata not found at specified URL
#0 3.357 History:
#0 3.357  - Signature /var/cache/zypp/raw/repo-non-ossjj6JxC/repodata/repomd.xml.asc not found.
#0 3.357  - Can't provide /repodata/repomd.xml
#0 3.357 
#0 3.357 Please check if the URIs defined for this repository are pointing to a valid repository.
#0 3.358 Warning: Skipping repository 'openSUSE-Tumbleweed-Non-Oss' because of the above error.
#0 3.359 Retrieving repository 'openSUSE-Tumbleweed-Oss' metadata [..
#8 CANCELED

Note that we see [repo-non-oss|http://download.opensuse.org/tumbleweed/repo/non-oss/] rather than the true URL of the failing mirror. As a result, it's difficult for us to report this to the mirror owner that their content is either missing or invalid.

It would be beneficial for users to isolate issues if the true mirror was shown after the redirections have occured such as:

repo-non-oss https://some-actual-mirror 
redirect from https://mirrorcache-au.opensuse.org 
redirect from https://download.opensuseorg

This way the full path can be isolated more easily.

Firstyear commented 1 year ago

Ping on this issue - we have seen multiple community reports of bad mirrors, but we can't diagnose which one is the issue without this feature. It's desperately needed because our community perception of opensuse as a distro is really suffering due to bad mirrors, and having tools so we can actually respond to these and provide updates will be so important.

Firstyear commented 1 year ago

@bzeller This has been an ongoing issue for our CI, and for helping users with mirror issues in the community. Could it be looked at please?

bzeller commented 1 year ago

@Firstyear We talked about this in the meeting today, but as usual this is not as straigth forward as it seems to be. Especially when chunking comes into play, writing redirect information for every chunk would be horrible. Also if multiple servers for a chunk fail which one would be the one we blame for the error etc...

We already log all redirects into the logfiles though.

Firstyear commented 1 year ago

Well, the issue is currently we have no information at all though when an error occurs which means finding a broken mirror (which happens more commonly than wed like) is near impossible when users report issues in the community.

So we do need a way to filter-up the true source of the error to the caller. While it may be challenging it's important for us to help identify which mirrors are impact our users negatively (which in turn negatively affects our reputation as a distribution).

yaleman commented 1 year ago

Some action on this would be nice - we can't troubleshoot why zypper commands are failing without the data about where it's pulling from.

Example error: https://github.com/kanidm/kanidm/actions/runs/5946810823/job/16127922982#step:5:216