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

Also available in: Atom PDF