Project

Profile

Help

Issue #6151

closed

associate-with-filter sometimes ends up with filtered-rpms in the destination

Added by ggainey over 2 years ago. Updated about 2 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
2.21.0
Platform Release:
2.21.1
OS:
Triaged:
Yes
Groomed:
Yes
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Sprint 66
Quarter:

Description

Description of problem: Creating a filter to exclude a package with a higher version that has multiple versions doesn't work properly on conservative dep-solving.

Version-Release number of selected component (if applicable): 2-master

How reproducible: 100%

Steps to Reproduce:

  1. Turn dependency solving to conservative.
  2. Create and sync custom repo.
  3. Create cv with depsolving on and add custom repo.
  4. Create exclusion filter and exclude a package (walrus) with a higher version
  5. Publish CV
  6. Check rpm package list for that version

Actual results: walrus 0.71 and 5.21 are present in rpm packages list.

Expected results: walrus 0.71 is the only package present in rpm packages list.

Additional info: Without depsolving, the filtering function works as expected.

Works as expected in 2.19


Files

reproducer (2.12 KB) reproducer Reproducer scripts - shows both walrus versions end up in repo ggainey, 02/12/2020 09:13 PM
Actions #2

Updated by ggainey over 2 years ago

John Mitsch's gist with his debugging information:

https://gist.github.com/johnpmitsch/e7aeeb6b518ef09feac7261058d0ee1e

Actions #3

Updated by ggainey over 2 years ago

This regression is the result of an attempt to make depsolving more robust in the face of multiple dependency-errors.

Prior to the commit mentioned in #1, find_dependent_solvables_conservative() would build a list of all the solvables resulting from the filtering provided to /associate, and then run solver.transaction() all at once. One of the changes made in that commit, is to instead solve per-unit, dealing with any fallout on a per-unit basis - see

https://github.com/pulp/pulp_rpm/blob/2-master/plugins/pulp_rpm/plugins/importers/yum/pulp_solv.py#L985-L986

and note that we are inside the "while solvables_to_copy' loop.

This works, until we get into the situation described here, where we have a unit (chimpanzee) that has a dependency (walrus) that we haven't seen yet, and which is in the source repo. Depsolving in isolation results in chimpanzee pulling in the most up-to-date version(s) of its dependencies that the Solver can find, resulting in walrus-5.21 being pulled in from the repo.

When depsolving happened for the entire list at once, it would find the walrus-0.71 from the list, in preference to the 5.21 from the repo, and all was well.

Working on figuring out what the best way to fix this is.

Actions #4

Updated by ggainey over 2 years ago

Added by ggainey over 2 years ago

Revision 792554f9

recursive-conservative needs to do one solve.transaction()

Doing one-per-solvable might be more robust, but leads to undesireable and/or inconsistent behavior depending on the ordering of the solvable-list. Reverting that specific piece of 39e310ab

closes #6151 https://pulp.plan.io/issues/6151

Actions #5

Updated by ggainey over 2 years ago

  • Status changed from ASSIGNED to POST
Actions #6

Updated by ggainey over 2 years ago

  • Status changed from POST to MODIFIED
Actions #7

Updated by ipanova@redhat.com over 2 years ago

  • Platform Release set to 2.21.1

Added by ggainey about 2 years ago

Revision abddb2b7

recursive-conservative needs to do one solve.transaction()

Doing one-per-solvable might be more robust, but leads to undesireable and/or inconsistent behavior depending on the ordering of the solvable-list. Reverting that specific piece of 39e310ab

closes #6151 https://pulp.plan.io/issues/6151

(cherry picked from commit 792554f9daaac33cc530194f1c3f26f5fb835371)

Actions #8

Updated by ggainey about 2 years ago

Actions #9

Updated by ipanova@redhat.com about 2 years ago

  • Status changed from MODIFIED to 5
Actions #10

Updated by ipanova@redhat.com about 2 years ago

  • Status changed from 5 to CLOSED - CURRENTRELEASE

Also available in: Atom PDF