Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2256074 - When a filter is added/removed from the CV and a new version is published/promoted, the capsule auto/manual sync is too slow.
Summary: When a filter is added/removed from the CV and a new version is published/pro...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Capsule - Content
Version: 6.15.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Satellite QE Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-12-28 09:08 UTC by mithun kalyat
Modified: 2024-01-10 19:02 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-01-10 19:02:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SAT-22166 0 None None None 2023-12-28 09:09:36 UTC

Description mithun kalyat 2023-12-28 09:08:03 UTC 
Description of problem:

Capsule auto sync is too slow when a filter is added/removed from the CV and published/promoted a new version.

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

Satellite 6.15

How reproducible:

Created a simple CV with the below repositories and an errata exclude filter, promoted and published to two environments.

----
Red Hat Enterprise Linux 8 for x86_64 - AppStream RPMs 8
Red Hat Enterprise Linux 8 for x86_64 - BaseOS RPMs 8
----

It took 20 to 40 minutes to complete the Capsule sync when two of the repositories below were added. Also, see the below error as well.

---
RuntimeError: Could not lookup a publication_href for repo 25
---

Removed the filter and again published and promoted a new version. Now it takes almost 40 minutes to complete the Capsule sync task.


Actual results:

Capsule sync is too slow.

Expected results:

With just two repositories in a CV, sync is expected to be much faster.

Additional info:

Attaching the screenshot of the filter/rule used in the CV.
Comment 3 Ian Ballou 2024-01-03 14:59:44 UTC 
It's hard to say since we're not sure how reproducible the issue is, but I would be surprised if it isn't doable for 6.15.0.

Mithun, did you have at least Pulpcore 3.28.19 on both you Satellite and Capsule? We did have a Capsule slowdown bug in Pulp but it was addressed in November.

Also, was your capsule syncing with the "immediate" download policy?

The "RuntimeError: Could not lookup a publication_href for repo 25" makes me think the system failed some prior step that may have made the sync take longer than usual. We'll try to reproduce it though.

If the original Satellite is available to take a look at, that would be helpful.
Comment 4 Ian Ballou 2024-01-03 15:04:25 UTC 
It would also be useful to know what part of the capsule sync was slow. The dynflow console would show that information.
Comment 5 Ian Ballou 2024-01-03 21:14:24 UTC 
Following the reproducing steps above, my first capsule syncs finished within 11 minutes and the second syncs (after removing filters) took under 6 minutes.

My Satellite has 4 cores and 25 GB RAM. My Capsule has 4 cores and 9 GB RAM.  

With the results I found, the speed doesn't seem any slower than it should be for the large RHEL 8 repositories.

I'm not sure why your syncs are over 4 times slower than mine, but it could depend on the test machine's specs and network connectivity.

The "Could not lookup a publication_href for repo 25" means that the smart proxy sync failed for some reason for the repository with ID 25.

---

So far I'm not seeing a performance issue yet. Mithun, can we see your environments specs (CPUs + RAM) and the full dynflow output of your sync tasks with the run times?
Note You need to log in before you can comment on or make changes to this bug.