Project

Profile

Help

Story #8673

Auto-publishing should be more fault-tolerant

Added by sskracic@redhat.com 3 months ago. Updated 6 days ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Sprint 101
Quarter:

Description

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

Related to Pulp - Task #8740: [EPIC] Publication based plugins should use either `distribution.repository` or `distribution.publication` but not bothNEW

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>
Related to RPM Support - Story #6353: As a user, I can mirror RPM repository content and metadataCLOSED - CURRENTRELEASE

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

History

#1 Updated by dalley 3 months ago

  • Related to Task #8740: [EPIC] Publication based plugins should use either `distribution.repository` or `distribution.publication` but not both added

#2 Updated by dalley 2 months ago

  • Related to Story #6353: As a user, I can mirror RPM repository content and metadata added

#3 Updated by dalley 2 months 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.

#4 Updated by dalley 2 months 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.

#5 Updated by sskracic@redhat.com 2 months 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.

#6 Updated by dalley 6 days ago

  • Sprint set to Sprint 101

Please register to edit this issue

Also available in: Atom PDF