Advisories clashing

Support
#1

Problem:
Trying to sync EPEL 8 Modular repository results in the Error

Incoming and existing advisories have the same id but different timestamps and intersecting package lists. It is likely that they are from two different incompatible remote repositories. E.g. RHELX-repo and RHELY-debuginfo repo. Ensure that you are adding content for the compatible repositories. Advisory id: FEDORA-EPEL-MODULAR-2020-2c76e38f8c

Expected outcome:
Repository syncs along with errata and advisories

Foreman and Proxy versions:

  • Foreman 2.3.2

Foreman and Proxy plugin versions:

  • foreman_tasks - 3.0.3
  • foreman_openscap - 4.1.2
  • foreman_remote_execution - 4.2.2

Distribution and version:
CentOS 7.9.2009

Other relevant data:

EPEL8 Modular
Basic Information
Name - EPEL8 Modular
Label - EPEL8_Modular
Description
Backend Identifier - 8cb3f075-2238-4124-a62c-983598e536fd
Type - yum
Sync Settings
Restrict to architecture - No restriction
Restrict to OS version - No restriction
Upstream URL - https://mirror.aarnet.edu.au/pub/epel/8/Modular/x86_64/
Verify SSL - Yes
Upstream Authorization
Yum Metadata - Checksum
Default
Mirror on Sync - No
HTTP Proxy - Global Default (HAIGS)
Ignorable Content
Publish via HTTPS - Yes
Publish via HTTP - Yes
Published At - http://foreman.domain/pulp/repos/ORG/Library/custom/EPEL8/EPEL8_Modular/
GPG Key - RPM-GPG-KEY-EPEL-8
SSL CA Cert
SSL Client Cert
SSL Client Key
Download Policy - Immediate

How do I go about debugging this?

#2

This error is coming from Pulp3, trying to decide what to do with an advisory that’s different ‘now’ than it was the last time you sync’d. You can see the error-message here:

https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/advisory.py#L177

What version of pulp_rpm do you have installed?

Can you get the version, updated_date, and package-list from advisory FEDORA-EPEL-MODULAR-2020-2c76e38f8c pre-sync?

2 Likes
#3

Interesting, that advisory in current-EPEL looks like this in updateinfo:

  <update from="updates@fedoraproject.org" status="stable" type="unspecified" version="2.0">
      <id>FEDORA-EPEL-MODULAR-2020-2c76e38f8c</id>
      <title>libuv-epel8_buildroot-820200423123233.9edba152</title>
      <issued date="2020-05-10 04:58:05"/>
      <updated date="2021-02-21 01:32:36"/>
      <rights>Copyright (C) 2021 Red Hat, Inc. and others.</rights>
      <release>Fedora Epel 8 Modular</release>
      <severity>None</severity>
      <summary>libuv-epel8_buildroot-820200423123233.9edba152 unspecified update</summary>
      <description>Fix dependency issue.</description>
      <references>
        <reference href="https://bugzilla.redhat.com/show_bug.cgi?id=1759510" id="1759510" type="bugzilla" title="Build libuv-devel for EPEL8"/>
      </references>
      <pkglist>
        <collection short="EPEL-8M">
          <name>Fedora Epel 8 Modular</name>
        </collection>
      </pkglist>
    </update>

If the earlier version had packages associated, and now it doesn’t, then we fall into the never-happen case. It’s possible the advisory was malformed somehow; maybe package maintainer can chime in here?

#4

Hi Grant,

Thanks for your input. It kinda helps but I’m thinking resolution is about deleting the offending repositories and starting again. Unfortunately I’ve run into another problem trying to delete the content view that has been published.

Error message: the server returns an error
HTTP status code: 400
Response headers: {“date”=>“Tue, 02 Mar 2021 21:49:17 GMT”, “server”=>“gunicorn/20.0.4”, “content-type”=>“application/json”, “vary”=>“Accept,Cookie”, “allow”=>“GET, DELETE, HEAD, OPTIONS”, “x-frame-options”=>“SAMEORIGIN”, “content-length”=>“39”, “via”=>“1.1 foreman.domain.au”, “connection”=>“close”}
Response body: [“Cannot delete repository version 0.”]

#5

That implies that katello is trying to delete repo-version-0 and not (or at least before) the repository it belongs to. I don’t know exactly what katello is doing at content-view-removal-time, maybe someone on that side of things can help.

#6

Hi @andyfry,

Your [“Cannot delete repository version 0.”] issue is definitely a bug. Does that content view have anything special like filtering, composites, or incremental updates?

To work around the problem, I think it would be save to just skip the action that is trying to delete the repo version 0 in the Dynflow console.