Issue #2248
closed
metadata file copy results in error 'Content import of FILENAME failed - must be an existing file'
Description
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.
Related issues
Updated by jsherril@redhat.com over 8 years ago
The only current way to resolve the issue is to run:
pulp-admin rpm repo remove metafile --repo-id=REPO_ID --match='repo_id=.*'
where REPO_ID is the repo you are copying from, resync the repo, and try the copy again.
Updated by ipanova@redhat.com over 8 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.
Updated by amacdona@redhat.com over 8 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.
Updated by ipanova@redhat.com almost 8 years ago
- Related to Issue #1944: YumMetadataFile copy does not save its new storage_path added
Updated by bmbouter over 5 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.
.