Red Hat Bugzilla – Bug 1085406
the UI is really uninformative about pulp's initial gyrations when syncing
Last modified: 2017-02-23 16:18:03 EST
Description of problem: snap 6 compose 2 When you first start syncing content, Pulp will fetch repodata from the upstream CDN and then start chewing on it. During this time, there is really nothing in the logs or in the UI regarding what's happening. It looks like Satellite is hung/stalled, but top will show that apache/wsgi is using a ton fo CPU power. Eventually (several minutes -- 5-7+) you will get some status update in the UI. It would be really beneficial to provide some indication on the sync status page about what's happening under the covers, especially during these times when pulp is doing "something" but providing no real feedback.
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
The sync management page is currently being updated to utilize dynflow. Once that is completed, let's re-evaluate if this is still an issue.
ejacobs | jsherrill: if you at least said "processing metadata" in the UI, that's better than what we've got ejacobs | jsherrill: and if yuo show the package count / percentage, that's 1,000,000x better
Should be addressed by https://github.com/Katello/katello/pull/4471
fixed by: https://bugzilla.redhat.com/show_bug.cgi?id=1122249
Now when syncing puppet modules - I see "Total module count: 301." and the empty progress bar. I also see dynflow tasks in Monitor -> Tasks - which also shows 0% and Output: Total module count: 301. Is this what is expected?
Failed. As per Comment 4 - "processing metadata" is not shown now. I will revisit this bug depending on @ejacobs response.
Version Tested: GA Snap 7 - Satellite-6.0.4-RHEL-6-20140829.0
Puppet syncing is never going to be as informative as syncing RPM based content. If we want to improve puppet syncing I'd vote we file a separate bug for this as the sync-mgmt page and Products -> Repos list is way more responsive now. Can you reconsider VERIFYING this?
Verified. Version Tested: Satellite-6.1.0-RHEL-6-20150210.0 Satellite-6.1.0-RHEL-7-20150210.0
This bug is slated to be released with Satellite 6.1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:1592