Ensure that pulp imports can run concurrently with orphan cleanup
CLOSED - DUPLICATE
Ticket moved to GitHub: "pulp/pulpcore/2021":https://github.com/pulp/pulpcore/issues/2021
I've confirmed that when an import happens, it bumps the timestamp_of_interest for artifacts and content so that when the import gets to the repository version creation step, the artifacts/content are still there.
However, I am not so sure that there isn't a possibly a race condition with django-import-export that could occur between when it selects the record(s) and then updates them. In fact, given the async problems we've seen in the past, I think it's likely.
I know we fixed another error similar to this:
And perhaps our fix for #8633 might save us here: the fix added code to retry the import if it experienced errors and perhaps that will also apply to this situation where an artifact/content goes missing before it's updated. We need to confirm this though.
- Sprint/Milestone set to 3.15.0
This needs to be done before we make orphan cleanup non-blocking but it doesn't necessarily need to be done as part of 3.14.
- Blocks Task #8824: Convert orphan cleanup into a non-blocking task added
- Status changed from NEW to ASSIGNED
- Assignee set to daviddavis
- Status changed from ASSIGNED to NEW
- Assignee deleted (
- Sprint/Milestone deleted (
Per our go/no-go meeting, we decided that a potential fix could be released as a z-stream and doesn't need to block the 3.15 release.
- Blocks deleted (Task #8824: Convert orphan cleanup into a non-blocking task)
- Parent task deleted (
- Sprint set to Sprint 107
- Sprint changed from Sprint 107 to Sprint 108
- Sprint changed from Sprint 108 to Sprint 109
- Sprint changed from Sprint 109 to Sprint 110
- Sprint changed from Sprint 110 to Sprint 111
- Sprint changed from Sprint 111 to Sprint 112
- Description updated (diff)
- Status changed from NEW to CLOSED - DUPLICATE
Also available in: Atom