SLES advisories cannot be successfully exported-imported because they have no name

[quba42]

Version
Affects all versions of pulp_rpm

Describe the bug
Because of the repometadata format used for advisories on SLES repos, such repos cannot be successfully exported and then re-imported.

To Reproduce
You need access to a SLES repo with advisories in it (requires a SUSE customer account).

Steps:

1. Sync your SLES repo
2. Export the SLES repo
3. Import the SLES repo

Import will fail with the unhelpful error INFO: Task 6453f373-be64-482d-9c89-d7472416bdb6 failed ('NoneType' object has no attribute 'pulp_id').

Expected behavior
Successful export/import of SLES repos containing advisories.

Additional context

The root cause can be seen as soon as you have synced a SLES repo with any advisories using the following DB query: SELECT * FROM rpm_updatecollection; You will see that SLES advisories all have the fields name, shortname, module set to None. Of these, only the name is needed for import/export, see:

• https://github.com/pulp/pulp_rpm/blob/main/pulp_rpm/app/models/advisory.py#L263
• https://github.com/pulp/pulp_rpm/blob/main/pulp_rpm/app/modelresource.py#L492

During sync the name field is set here:

• https://github.com/pulp/pulp_rpm/blob/main/pulp_rpm/app/models/advisory.py#L285

Looking at fedora epel metadata we see for example:

  <update from="updates@fedoraproject.org" status="stable" type="bugfix" version="2.0">
    <id>FEDORA-EPEL-2020-f56ff5d88d</id>
    <title>tarantool-1.10.7.33-1.el7</title>
    <issued date="2020-09-19 21:00:36"/>
    <updated date="2020-10-04 00:30:26"/>
    <rights>Copyright (C) 2023 Red Hat, Inc. and others.</rights>
    <release>Fedora EPEL 7</release>
    <severity>Low</severity>
    <summary>tarantool-1.10.7.33-1.el7 bugfix update</summary>
    <description>Update to the latest LTS release</description>
    <references/>
    <pkglist>
      <collection short="EPEL-7">  # This is recorded as 'shortname' in Pulp !!!!!!!!!!!!!!!!!!!!!!!
        <name>Fedora EPEL 7</name>  # This is recorded as 'name' in Pulp !!!!!!!!!!!!!!!!!!!!!!!
        <package name="tarantool" version="1.10.7.33" release="1.el7" epoch="0" arch="src" src="https://download.fedoraproject.org/pub/fedora/linux/updates/7/SRPMS/t/tarantool-1.10.7.33-1.el7.src.rpm">
          <filename>tarantool-1.10.7.33-1.el7.src.rpm</filename>
        </package>
        <package name="tarantool" version="1.10.7.33" release="1.el7" epoch="0" arch="x86_64" src="https://download.fedoraproject.org/pub/fedora/linux/updates/7/x86_64/t/tarantool-1.10.7.33-1.el7.x86_64.rpm">
          <filename>tarantool-1.10.7.33-1.el7.x86_64.rpm</filename>
        </package>
        <package name="tarantool-devel" version="1.10.7.33" release="1.el7" epoch="0" arch="x86_64" src="https://download.fedoraproject.org/pub/fedora/linux/updates/7/x86_64/t/tarantool-devel-1.10.7.33-1.el7.x86_64.rpm">
          <filename>tarantool-devel-1.10.7.33-1.el7.x86_64.rpm</filename>
        </package>
        <package name="tarantool-debuginfo" version="1.10.7.33" release="1.el7" epoch="0" arch="x86_64" src="https://download.fedoraproject.org/pub/fedora/linux/updates/7/x86_64/t/tarantool-debuginfo-1.10.7.33-1.el7.x86_64.rpm">
          <filename>tarantool-debuginfo-1.10.7.33-1.el7.x86_64.rpm</filename>
        </package>
      </collection>
    </pkglist>
  </update>

SLES repos simply do not have anything corresponding to short="EPEL-7" and <name>Fedora EPEL 7</name> above in their repo metadata.

[quba42]

It strikes me as very questionable design that the UpdateCollection class, has a nullable name field:

https://github.com/pulp/pulp_rpm/blob/main/pulp_rpm/app/models/advisory.py#L254

But also uses this field for the uniqueness constraints:

https://github.com/pulp/pulp_rpm/blob/main/pulp_rpm/app/models/advisory.py#L263

I propose we find some fall back value for this field in case the repo we sync does not supply anything. That would solve this issue. I also propose we migrate existing data to retroactively use the new fallback value, and declare the field as not nullable. Alternative approaches welcome.

[quba42]

Update: We found a SUSE spec for the relevant repometadata, that does not include the existence of the relevant name field: https://en.opensuse.org/openSUSE:Standards_Rpm_Metadata_UpdateInfo

[dralley]

Update: We found a SUSE spec for the relevant repometadata, that does not include the existence of the relevant name field: https://en.opensuse.org/openSUSE:Standards_Rpm_Metadata_UpdateInfo

Well, note that it's present in both their example and the documentation underneath it, but not in the XML schema itself. So the documentation and the provided schema aren't fully consistent with each other either.

That being said, it's a valid issue, I'll take a look at your proposed fix.