This prevents Katello from syncing the repository with Download Mode “Immediate”. Changing the Mirroring Policy does not seem to have an effect.
Currently Katello issues a 404 warning on the missing package (which is correct) but then immediately stops synchronizing the repo which results in either an outdated repo (if it existed before the error was introduced in the metadata) or a completely empty repo on Katello.
I’m aware that the issue should be fixed on Rocky side, but I’m wondering if this should be the correct behavior for Katello ?
The only workaround I found so far is using download mode “On Demand” which has other drawbacks of potentially loosing access to old versions of packages if upstream decides to remove them
Expected outcome:
Katello issues warning about missing package but continues sync of metadata and packages which are available.
Yes, I would say it is correct behavior as I would expect it to provide me only with a valid repository. But then it should also fail with different settings. But I can also understand you want a more fault-tolerant behavior. How would it it look like in your opinion? Should it simply download everything and provide the same broken metadata or should it then generate valid metadata based on the available packages? This could also be caused by a broken mirror, so how should be the error or warning be shown? How to handle then broken errata? I think if we can find answers to this quests developers would be open for changes.
But do I understand correctly that Rocky provides broken metadata for a half year and handles this as a small error?
But do I understand correctly that Rocky provides broken metadata for a half year and handles this as a small error?
Yes, seems like…I also would have expected this to be fixed much faster…Now it was supposed to be fixed with 9.6 but it isn’t…Also kind of concernig to me…
My expectation would be:
“Complete Mirroring” just replicates whatever error is present in the metadata
“Content Only” has fixed metadata, if possible
Also wondering if a 404 completely stops a sync, shouldn’t it be an error instead of a warning ?
We had a content view on the base, appstream and devel repo we did not update for a long time.
Since the devel repo only showed a warning about a package we were not using, we did not think there was something seriously wrong.
So then after updating the content view recently, we ended up with a set of repositories that did not fit together and created conflicts on system updates since base and appstream where freshly synced and the state of devel was several months old which we did not recognize.
This ticket is already more than a year old, but I believe the demand for the feature still exists. There is some concern that starting to introduce workarounds like this will result in an ever escalating series of requests along the lines of “I know this upstream repo is broken in X way, but can we just add one more workaround for X?”, but at the same time the need is generally recognized.
I agree it would be nice for Pulp to ignore the metadata for content that doesn’t exist, but I’m not sure how feasible that would be without slowing down sync time dramatically. If content were to be ignored, would a simple package option work? Or are there perhaps other kinds of content that can result in 404s?
We use a warning so that the sync task doesn’t end up in a Paused state in Dynflow. If a sync is Paused, the repository lock is held on to and you cannot resync the repository.
For a workaround - If the repository syncs fine using on demand content, my suggestion would be to put the content in a content view for now and filter out the module stream that is causing trouble.
