Story #8673
closed
Auto-publishing should be more fault-tolerant
Status:
CLOSED - DUPLICATE
Description
Ticket moved to GitHub: "pulp/pulp_rpm/2273":https://github.com/pulp/pulp_rpm/issues/2273
I admit the title is a bit vague.
During auto-publishing sync of a very large repository (rhel-7-server-rpms), the rq process got killed by oom-killer sometime in the middle of the publishing step. So the new repository version (1) got created, but accompanying
publication did not.
On the subsequent sync runs, the repository did not get published, as no new content was available to sync, hence a new repository version was not created, which in turn should trigger publication and distribution update.
Of course, the repo can still be published and distributed using the non-autopublishing REST API, but I wonder whether the behavior was intended.
- Related to Task #8740: [EPIC] Publication based plugins should use either `distribution.repository` or `distribution.publication` but not both added
- Related to Story #6353: As a user, I can mirror RPM repository content and metadata added
#6353 should help with this, since metadata mirroring avoids the need for a publishing step - even via auto-publishing.
Although of course for custom repos, auto-publish is necessary to make repo modifications convenient.
@sskracic I would call this "an expected but unfortunate corner case". In this situation, which would you prefer to happen?
- The current behavior (with maybe some additional logging of warnings)
- Have entire task fail and all changes reverted, including the destruction of the repository version that was created. This means that the operation that created the repository version would need to be re-done in its entirety.
dalley wrote:
@sskracic I would call this "an expected but unfortunate corner case". In this situation, which would you prefer to happen?
- The current behavior (with maybe some additional logging of warnings)
- Have entire task fail and all changes reverted, including the destruction of the repository version that was created. This means that the operation that created the repository version would need to be re-done in its entirety.
If feasible, I would prefer the latter. My understanding is that with the artifacts already being downloaded, only their associations to the new repo version will need to be redone on the next sync run.
- Sprint changed from Sprint 101 to Sprint 102
- Sprint changed from Sprint 102 to Sprint 103
- Sprint changed from Sprint 103 to Sprint 104
- Sprint changed from Sprint 104 to Sprint 105
- Priority changed from Normal to Low
- Sprint changed from Sprint 105 to Sprint 106
- Sprint changed from Sprint 106 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
- Description updated (diff)
- Status changed from NEW to CLOSED - DUPLICATE
Also available in: Atom
PDF
.