Project

Profile

Help

Issue #2263

closed

Fast-forward yum publish skips units if previous publish was cancelled

Added by rmcgover over 7 years ago. Updated about 5 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
High
Assignee:
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
3. High
Version:
2.10.0
Platform Release:
2.12.1
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Sprint 14
Quarter:

Description

If a yum publish is triggered on a repo, then cancelled before completion, that publish still sets last_publish on the distributor despite being cancelled.

The next yum publish of that repo will then look for units associated after that last_publish, incorrectly skipping any units which hadn't been published due to the cancellation.

Steps to reproduce:

1. Trigger yum distributor on repo, allow it to succeed.
2. Trigger yum distributor on repo.
3. Cancel task from previous step after it starts but before it publishes the RPMs (may have to be quick)
4. Trigger yum distributor on repo, allow it to succeed.

Actual behavior:

  • the task triggered at step 4 completes with "summary": "Skipped: Repository content has not changed since last publish."
  • the RPMs associated at step 2 aren't published

Expected behavior:

  • the task triggered at step 4 publishes the RPMs associated at step 2

Note: because yum publish of a small repo will be quite fast, I used a patch like this while reproducing it:

diff --git a/plugins/pulp_rpm/plugins/distributors/yum/publish.py b/plugins/pulp_rpm/plugins/distributors/yum/publish.py
index cb08d75..5914d58 100644
--- a/plugins/pulp_rpm/plugins/distributors/yum/publish.py
+++ b/plugins/pulp_rpm/plugins/distributors/yum/publish.py
@ -386,6 +386,11 @ class InitRepoMetadataStep(platform_steps.PluginStep):
self.parent.get_checksum_type())
self.parent.repomd_file_context.initialize()

+ logger.info("SLEEPING FOR TEST!!!")
+ import time
+ time.sleep(60)
+ logger.info("END SLEEPING FOR TEST!!!")
+

class CloseRepoMetadataStep(platform_steps.PluginStep):

In practice in our installation we've seen this issue affecting larger repos, where it'd be easier to reproduce since tasks have more time to be cancelled.

Also available in: Atom PDF