A case has been noticed that a newly deployed RPM into a Yum hosted repository may not automatically end up referenced in the repodata / filelists.xml.gz file.
When an rpm is deployed into a yum hosted repository, then an automatic yum metadata rebuild is scheduled to run 60 seconds later.
The following steps reproduced by a customer resulted in a filelists.xml.gz file that was not updated with the newly deployed RPM.
- a yum hosted repo
- an RPM file - in the case of the reproduce the file available at this page was used: hp-health-10.70-1846.6.rhel7.x86_64.rpm.
Using a yum hosted repo with redeploy allowed, upload an RPM
1. upload the RPM using curl to the root of the hosted repo using the name of the file.
2. Wait for the yum metadata rebuild to execute after 60s and then complete
3. While the Browse UI is opened, navigate to the repository where the rpm was uploaded, expand the repodata browse node, select and then click the link to download the file ending in filelists.xml.gz - note the name of the file which is uniquely named base on what the file contains. Confirm the downloaded file contains reference to uploaded file.
4. Using the Browse UI, navigate to the entry for the RPM that was uploaded. Select it. Click the Delete Asset button to delete the rpm file. This delete operation will automatically schedule a rebuild metadata task to run after 60 seconds. Wait for the task to execute and complete.
5. Using the Browse UI, download the new filelists.xml.gz file. Notice the file name is different, the size smaller and the downloaded file no longer contains the removed rpm, as expected.
6. Upload the exact same RPM again ( Step 1 ) and wait for rebuild ( Step 2).
7. Problem: Download the filelists.xml.gz file ( Step 3). Notice it has changed in name, but not in size, suggesting it does not contain the new reference, but was rebuilt. One can grep the file to verify it does not in fact contain a reference to the re-uploaded rpm.
A full rebuild of the yum hosted repository metadata using a scheduled task will create a filelists.xml.gz file that does contain the newly uploaded file.
It was also noticed that unlike the automated rebuild on upload/delete, the scheduled task will take significantly longer to rebuild the metadata for the entire hosted repo.