Story #8673
closed
Auto-publishing should be more fault-tolerant
0%
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 issues
Updated by dalley over 3 years ago
- Related to Task #8740: [EPIC] Publication based plugins should use either `distribution.repository` or `distribution.publication` but not both added
Updated by dalley over 3 years ago
- Related to Story #6353: As a user, I can mirror RPM repository content and metadata added
Updated by dalley over 3 years ago
#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.
Updated by dalley over 3 years ago
@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.
Updated by sskracic@redhat.com over 3 years ago
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.
Updated by ipanova@redhat.com over 3 years ago
- Sprint changed from Sprint 101 to Sprint 102
Updated by rchan about 3 years ago
- Sprint changed from Sprint 104 to Sprint 105
Updated by rchan about 3 years ago
- Sprint changed from Sprint 105 to Sprint 106
Updated by rchan about 3 years ago
- Sprint changed from Sprint 106 to Sprint 107
Updated by rchan about 3 years ago
- Sprint changed from Sprint 107 to Sprint 108
Updated by rchan about 3 years ago
- Sprint changed from Sprint 108 to Sprint 109
Updated by rchan about 3 years ago
- Sprint changed from Sprint 109 to Sprint 110
Updated by rchan almost 3 years ago
- Sprint changed from Sprint 110 to Sprint 111
Updated by pulpbot almost 3 years ago
- Description updated (diff)
- Status changed from NEW to CLOSED - DUPLICATE
.