Network maintenance. Planio will be observing two scheduled maintenance windows this Tuesday, March 2 and Wednesday, March 3 from 02:00 UTC until 06:00 UTC each in order to perform maintenance on access routers in our primary datacenter. Your account might observe short downtimes during these periods up to several minutes at a time.
metadata file copy results in error 'Content import of FILENAME failed - must be an existing file'
similar to https://pulp.plan.io/issues/1944
Its currently unknown how a user gets into this state, but a user claimed that even after upgrading to 2.8.6 performing a metadatafile copy from a particular repo to another particular repo failed with:
Content import of /var/lib/pulp/content/units/yum_repo_metadata_file/39/abae87235cc1942704eac508ecd5112de03252b757d8f213fd4aafb4f08488/productid.gz failed - must be an existing file.
The same metadata copy worked fine previously after upgrading to 2.8.6.
This was on a katello server where orphan cleanup is run weekly. Its very possible it was run since the last successful copy.
#2 Updated by email@example.com over 4 years ago
How to reproduce that:
1. create repo1 and sync it ( with #1944 present)
2. create repo2
3. copy yum_metadata_file from repo1 to repo2( there will in db 2 units of yum_metadata_file that will reference same storage_path due to #1944)
4. Remove repo2
5. Notice 1 yum_metadata_file among orphans
6. Clean orphans( since in db 2 units of yum_metadata_file reference same storage_path, remaining unit after orphan clean will reference to non-existing storage path)
7. Upgrade to 2.8.6, run migration( it will calculate correct storage path) + #1944 will be fixed at this point.
8. create repo3
9. copy from repo1 to repo3
10. observe traceback.
I am not sure if that can be fixed, that is just concatenation of circumstances where if you did all the steps listed above in same order you have no other choice than just re-sync repo. And if it is a repo without feed...then you're in very unpleasant non recoverable state.
#3 Updated by firstname.lastname@example.org over 4 years ago
- Priority changed from Normal to High
- Severity changed from 3. High to 2. Medium
- Triaged changed from No to Yes
Priority is set high to investigate this. If it cannot be fixed, then the issue should be changed to making the recovery more accessible in a release note or troubleshooting doc.
#5 Updated by bmbouter almost 2 years ago
- Status changed from NEW to CLOSED - WONTFIX
Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.
Please register to edit this issue