Repo metadata should update on successful sync
I have observed the following sequence on my pulp 2.5.1 installation:
1) pulp-admin rpm repo sync run --repoid=epel-7-x86_64
Sync completes successfully
2) yum upgrade
Yum find dependency problems with createrepo_c package, needs >= 0.4, only 0.3.1 available.
4) check the published files, createrepo_c 0.7 is published by html.
Perhaps the client cache is out of date?
5) yum clean all
6) yum update
Same problem with createrepo_c package
I have observed this problem before, and I think that I fixed it on that occasion by deleting the repo and re-creating it from scratch. As I didn't purge orphans, the sync only downloaded the repo metadata.
I have not been able to verify the fix to this problem as at 1 May 2015 due to another issue with synching epel (Btree::insert key too large to index).
Sorry, I don't know how to reproduce this problem from scratch.
Correct metadata is always published.
Is there a way to purge any existing published metadata, to ensure that metadata is re-generated?
Updated by mhrivnak about 7 years ago
Please attach the corresponding XML file from the published repo. You can find it by looking in the "repodata" directory in the base of your published repo, and then look for a file whose name ends in "primary.xml.gz".
After the sync, a publish task should also get queued. It would be helpful to double-check that the publish task didn't report any errors. You could alternatively start a new publish with "pulp-admin rpm repo publish run", and see if that has any errors.
Updated by Ben.Stanley about 7 years ago
This issue is likely to be a symptom of issue #943, the long running epel long errata title problem saga.
To try to work around #943, I deleted my epel-7-x86_64 repo, and tried to re-create it from scratch.
When I sync epel-7-x86_64, the sync fails in the errata part (error described in issue #943).
Consequently, the repo is not published, and I have no repomd.xml file to send you.
I suspect that what I reported here may be simply that the repomd.xml file was not updated due to the errata error, and that I was seeing an older version.
Perhaps we should consider here: Can we make the publishing behaviour any more robust and useful in the face of adverse conditions?
Is it appropriate or possible to publish the new repomd.xml if the errata is erroneous?
I don't use the errata, so total sync failure caused by bad errata causes me significant frustration.