Project

Profile

Help

Issue #7716

closed

Incremental export not happening if last export was null even if start_version is provided

Added by paji@redhat.com about 4 years ago. Updated almost 4 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Sprint 84
Quarter:

Description

Katello needs to be able to control the versions being exported. Pulp 3 introduced the start_versions and versions exporting for incremental in https://pulp.plan.io/issues/6763 . This api seems to do the correct thing, however it assumes that incremental is not possible if last_export has not been set before on the exporter. While this condition makes sense its unnecessary since none of exporter code cares about last_export if pulp was passed start_versions to begin with.

The line of code I am referring to is https://github.com/pulp/pulpcore/blob/master/pulpcore/app/tasks/export.py#L145-L146

def _incremental_requested(the_export):
    """Figure out that a) an incremental is requested, and b) it's possible."""
    the_exporter = the_export.exporter
    full = the_export.params.get("full", True)
    if isinstance(full, str):
        full = bool(strtobool(full))
    last_exists = the_exporter.last_export
    return last_exists and not full

I propose removing the last_exists condition or do something like "if start_version was not provided then you must have a last_export for incremental". OTOH "if start_version WAS provided then ignore last_export for incremental"


Related issues

Related to Pulp - Backport #7725: Backport Request: 7716 (Incremental export not happening if last export was null even if start_version is provided)CLOSED - CURRENTRELEASEttereshc

Actions
Actions #1

Updated by ggainey about 4 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to ggainey
  • Sprint set to Sprint 84
Actions #2

Updated by ggainey about 4 years ago

Outstanding catch. I suspect this check is left over from before the requirement for start_versions= was added - so doing an incremental made zero sense unless there had been a previous export.

Actions #3

Updated by pulpbot about 4 years ago

  • Status changed from ASSIGNED to POST
Actions #4

Updated by ttereshc about 4 years ago

  • Triaged changed from No to Yes
Actions #5

Updated by ttereshc about 4 years ago

  • Related to Backport #7725: Backport Request: 7716 (Incremental export not happening if last export was null even if start_version is provided) added

Added by paji@redhat.com about 4 years ago

Revision 8b1531c8 | View on GitHub

fixes #7716 - Incremental export to happen if start_version provided, even if last_export is null

Actions #6

Updated by paji@redhat.com about 4 years ago

  • Status changed from POST to MODIFIED
Actions #7

Updated by daviddavis almost 4 years ago

  • Sprint/Milestone set to 3.9.0
Actions #8

Updated by pulpbot almost 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF