Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
+++ This bug was initially created as a clone of Bug #1014663 +++
+++ This bug was initially created as a clone of Bug #1014390 +++
Content View publishing of a moderate sized repo (3k packages, RHEL 6.4-x86_64) takes 20+ minutes to publish the first content view in MDP2
2013-10-01T16:07:48-0400: [Worker(delayed_job host:dhcp-8-30-94.lab.eng.rdu2.redhat.com pid:18493)] ContentViewDefinition#generate_repos completed after 1328.9986
With MDP1 it takes around 3 minutes:
2013-09-08T12:11:41-0400: [Worker(delayed_job host:satellite6.usersys.redhat.com pid:2493)] ContentViewDefinition#generate_repos completed after 372.8071
Steps to reproduce:
1) Enable RHEL 6.4 x86_64 from Red Hat repositories
2) Sync
3) create a content view with only this one repo in it, no filters
4) publish
wait 20 minutes ...
We are touting MDP2 to be faster with CV publishing and it doesn't appear to be so.
--- Additional comment from RHEL Product and Program Management on 2013-10-01 17:17:44 EDT ---
Since this issue was entered in Red Hat Bugzilla, the pm_ack has been
set to + automatically for the next planned release
--- Additional comment from David Davis on 2013-10-02 09:14:08 EDT ---
Publishing a definition with only two small zoo repos is taking about 100 seconds. 93 seconds are being spent in ContentViewDefinition#generate_repos. Here's a breakdown of the times.
32 seconds
https://github.com/Katello/katello/blob/cc81e688b0d01deb19b6e85a7d5d094ad17e186e/app/models/content_view_definition.rb#L292-L294
34 seconds
https://github.com/Katello/katello/blob/cc81e688b0d01deb19b6e85a7d5d094ad17e186e/app/models/content_view_definition.rb#L311-L312
23 seconds
https://github.com/Katello/katello/blob/cc81e688b0d01deb19b6e85a7d5d094ad17e186e/app/models/content_view_definition.rb#L89
95% of the time here is spent waiting on Pulp.
--- Additional comment from David Davis on 2013-10-02 09:19:11 EDT ---
Here is the pulp log:
https://gist.github.com/daviddavis/a8d6bcc8ce82afe489da
--- Additional comment from David Davis on 2013-10-02 09:22:47 EDT ---
I'm using pulp 2.3.0-0.12.alpha but I believe MDP2 may be on 2.3.0-0.14.alpha.
--- Additional comment from David Davis on 2013-10-02 10:08:52 EDT ---
Here are the calls we're making to pulp:
https://gist.github.com/daviddavis/6794355
The repo urls:
http://mmccune.fedorapeople.org/discovery/zoo/http://mmccune.fedorapeople.org/discovery/zoo_ks2/
--- Additional comment from David Davis on 2013-10-03 16:36:05 EDT ---
So I found out the wait times were not because of pulp but because of the code in the method we use to poll pulp tasks' statuses. By changing the sleep time, we were able to reduce the times for the repos in comment #1 from 100+ seconds to less than 30 seconds.
--- Additional comment from Barnaby Court on 2013-10-04 14:25:45 EDT ---
Partha verified that running with a larger repo (rhel) synced in a smaller amount of time. This report is being treated as an anomaly and if get further reports we will re-open it.
--- Additional comment from Preethi Thomas on 2013-10-04 15:08:24 EDT ---
Moving to verified as per the above comments.