pulp
Auto-publishing should be more fault-tolerant
Author: [email protected] ([email protected])
Redmine Issue: 8673, https://pulp.plan.io/issues/8673
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.
From: @dralley (dalley) Date: 2021-05-13T13:40:51Z
#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.
From: @dralley (dalley) Date: 2021-05-27T02:49:45Z
@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.
From: [email protected] ([email protected]) Date: 2021-05-27T13:20:18Z
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.