Project

Profile

Help

Issue #8229

Do not replace advisory if only 'updated_date' has changed

Added by adam.winberg@smhi.se 10 months ago. Updated 6 months ago.

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

Description

It seems that EPEL sets a new 'updated_date' every day, so when I run my daily sync I get:

    "content_summary": {
        "added": {
            "rpm.advisory": {
                "count": 2540,
                "href": "/pulp/api/v3/content/rpm/advisories/?repository_version_added=/pulp/api/v3/repositories/rpm/rpm/10e51ae6-65c7-42aa-8ab1-ffebdf752500/versions/19/"
            },
            "rpm.package": {
                "count": 6,
                "href": "/pulp/api/v3/content/rpm/packages/?repository_version_added=/pulp/api/v3/repositories/rpm/rpm/10e51ae6-65c7-42aa-8ab1-ffebdf752500/versions/19/"
            }
        },
        "removed": {
            "rpm.advisory": {
                "count": 2536,
                "href": "/pulp/api/v3/content/rpm/advisories/I've tested this and it works?repository_version_removed=/pulp/api/v3/repositories/rpm/rpm/10e51ae6-65c7-42aa-8ab1-ffebdf752500/versions/19/"
            }
        }
    },

Inspecting the advisories, the only thing changed is the 'updated_date' metadata, version and package lists are identical. EPEL seems to set a new 'updated_date' each day on existing advisories, and in such a case there is not much sense in replacing the existing advisory with the 'new' one. I run weekly scripts to copy new advisories to a frozen repo which is a lot harder to do when thousands of new advisories are coming in every day.

I looked at the code ("pulp_rpm/app/advisory.py") and propose that an additional test is made in the "resolve_advisory_conflict" function, a crude example:

    elif not same_dates and pkgs_intersection:
        if same_version and previous_pkglist == added_pkglist:
            # Ignore new advisory if only 'updated_date' has changed
            to_exclude.append(added_advisory.pk)

History

#1 Updated by dalley 9 months ago

  • Triaged changed from No to Yes

#2 Updated by ggainey 9 months ago

  • Priority changed from Normal to Low

We're planning to reach out to EPEL folks to see why this happens - would rather fix it at the source, than add a tweak that would mean never updating advisories that only have metadata/text changes. Will revisit shortly.

#3 Updated by dalley 9 months ago

Issue filed with Fedora release engineering (which manages EPEL) here: https://pagure.io/releng/issue/10051

#5 Updated by ggainey 9 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to ggainey

#6 Updated by ggainey 9 months ago

If/when bodhi accepts this PR, the problem will be solved in the right place :

https://github.com/fedora-infra/bodhi/pull/4190

#7 Updated by dalley 9 months ago

  • Status changed from ASSIGNED to MODIFIED
  • Assignee changed from ggainey to dalley

Bodhi has merged our PR to fix the issue: https://github.com/fedora-infra/bodhi/issues/4189

I'm not sure when the fix goes live in their production instance, but this behavior should stop when it does so.

#8 Updated by dalley 9 months ago

  • Status changed from MODIFIED to CLOSED - NOTABUG

Going to go ahead and close this -- but I'll update once we test it to verify that EPEL is fixed.

#9 Updated by dalley 8 months ago

A new Bodhi release was pushed yesterday, so possibly this will be fixed in production soon. Will verify.

#10 Updated by dalley 6 months ago

Verified, EPEL is fixed, updated_date is no longer updating constantly.

Please register to edit this issue

Also available in: Atom PDF