Project

Profile

Help

Issue #2248

metadata file copy results in error 'Content import of FILENAME failed - must be an existing file'

Added by jsherril@redhat.com about 4 years ago. Updated over 1 year ago.

Status:
CLOSED - WONTFIX
Priority:
High
Assignee:
-
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
2.8.6
Platform Release:
OS:
CentOS 7
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:

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

Related to RPM Support - Issue #1944: YumMetadataFile copy does not save its new storage_pathCLOSED - CURRENTRELEASE<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

History

#1 Updated by jsherril@redhat.com about 4 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.

#2 Updated by ipanova@redhat.com about 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 amacdona@redhat.com about 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.

#4 Updated by ipanova@redhat.com over 3 years ago

  • Related to Issue #1944: YumMetadataFile copy does not save its new storage_path added

#5 Updated by bmbouter over 1 year 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.

#6 Updated by bmbouter over 1 year ago

  • Tags Pulp 2 added

Please register to edit this issue

Also available in: Atom PDF