Bug 1771780 - Dep-Solving with additional repositories makes CV publish action much slower than expected.
Summary: Dep-Solving with additional repositories makes CV publish action much slower ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Pulp
Version: 6.7.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Lai
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-12 23:24 UTC by Partha Aji
Modified: 2023-10-06 18:46 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-02 15:17:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github pulp pulp_rpm issues 2298 0 None open Dependency solver takes an extremely long time to be loaded with content 2022-09-02 15:38:14 UTC

Description Partha Aji 2019-11-12 23:24:16 UTC
Description of problem:
When publishing a content view with dep solve turned on, satellite now includes additional repositories in the same content view. While this works well it doubles typical depsolve publish time.

Version-Release number of selected component (if applicable): 6.7 and above


Steps to Reproduce:
1. Create a content view with a bunch of RHEL repositories
2. Add a  module includes filter
3. Turn depsolve on the content view
4. Check on the publish time 

Actual results:
In my environment with AppStream and BaseOS
- No Depsolve - 11s
- Dep Solve without additional repos (look at single repo only.): 90s
- Dep Solve with "additional-repositories" : 204s

Wondering whether we need a setting or option to turn off multi-repo  lookup.

Comment 4 Daniel Alley 2019-11-14 14:33:50 UTC
The issue here is not the depsolving itself, but the preparation needed to be able to do the depsolving. Specificially, metadata about every single RPM, module, etc. in every repository considered by the depsolving must be fetched from the database and loaded into the depsolver. The amount of querying and IO this requires makes it fundamentally somewhat slow, and we're already bypassing mongoengine and making raw Mongo queries to reduce overhead and increase speed, so I'm not sure what more we can do without introducing caching which would be very difficult to get correct (cache invalidation issues, etc.)

Comment 5 Mike McCune 2022-07-08 17:15:31 UTC
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Comment 7 Brad Buckingham 2022-09-02 20:08:50 UTC
Thank you for your interest in Red Hat Satellite. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to contact your Red Hat Account Team. Thank you.


Note You need to log in before you can comment on or make changes to this bug.