Project

General

Profile

Actions

Bug #38218

open

CV with depsolving and filters on selected repos is broken at orhpan cleanup

Added by Pavel Moravec 5 days ago. Updated 3 days ago.

Status:
Ready For Testing
Priority:
Normal
Assignee:
Category:
Content Views
Target version:
Difficulty:
easy
Triaged:
Yes
Fixed in Releases:
Found in Releases:

Description

Description of problem:
There is a bug in publishing a CV that:

  • has dependency solving enabled
  • has some filter applied to a subset of repositories

Then, katello repositories from the published CV version for repos not in the filter are wrongly populated in katello - references to pulp are invalid.

Subsequent repos sync + CV publish + orphan cleanup then creates different issues (depending on katello version and ordering of steps). Basic problem applies on 4.14 where orhpan cleanup gets broken (if nothing else).

Technically, for such Repository, katello copies the publication from the root repository - but sets `version_href` to some another (cloned) repository. Such that katello data have same pulp publication "associated" with two different pulp repository (version).

How reproducible:
100%

Is this issue a regression from an earlier version:
nope, just behaves differently badly on different katello version. Root cause bug is the same

Steps to Reproduce:

  1. Have a CV with dependency solving enabled and a filter (e.g. "exclude RPM package") applied to just one repo.
  2. Publish v 1.0 of the CV
  3. For the repo in CV that the filter is not applied to, sync or upload some new content.
  4. Run orphan cleanup
  5. After each previous step, check katello repositories and their references to pulp, like:

(in psql console):


foreman=# select root_id,relative_path,version_href,publication_href from katello_repositories where (relative_path like '%/Library/content/%' or relative_path like '%/Library/custom/%' or relative_path like '%/content_views/%') and root_id in (10, 13) order by root_id,relative_path;

Actual behavior:
In 4.14 (rather depends on pulp version, though), the remove orphans fails on "The repository version cannot be deleted because it (or its publications) are currently being used to distribute content. Please update the necessary distributions first." error.

Depending on variants of the scenario (e.g. promoting the CV to some LE afterwards, creating a new CV version, clients accessing content), you can get nonexisting Publication error or even 404 errors when accessing repo metadata from clients. But the 4.14's remove orphans error is sufficient reproducer for the underlying bug.

Once the CV version 1.0 is published, you will see in postgres:

13 | MyOrg/content_views/cv_test/9.0/custom/sos_product/sos_repo       | /pulp/api/v3/repositories/rpm/rpm/431cd571-34a0-4dac-84e6-c569732b9a48/versions/9/  | /pulp/api/v3/publication
s/rpm/rpm/aaf500b0-3d02-4bf2-bb78-4726baafcbb4/
13 | MyOrg/Library/custom/sos_product/sos_repo | /pulp/api/v3/repositories/rpm/rpm/c99aa022-43d9-4c01-9cd7-6827e14198e3/versions/2/ | /pulp/api/v3/publication
s/rpm/rpm/aaf500b0-3d02-4bf2-bb78-4726baafcbb4/

I.e. the root repo and CV version repo both point to the same pulp publication, BUT to different repo (version).

Once the repo synces or gets uploaded a new content, it's repo version bounces and publication changes.

Once orphan cleanup is run, it detects the previous root repo pulp repoversion (`c99aa022-43d9-4c01-9cd7-6827e14198e3/versions/2/` here) is obsolete, so it tries to delete it - and pulp cascade-ly deletes its Publication (in older pulp versions), or it raises the error above.

Expected behavior:
Orphan removal task does work. Technically, CV version create should create katello repository with coherent references to pulp.

Actions

Also available in: Atom PDF