+++ This bug was initially created as a clone of Bug #1260141 +++ Description of problem: During content view publish there are a number of 'update schedule' tasks that are executing within the publish task that are not needed. These are setting the schedule on the Library repos. In addition, whenever publishing any repositories that are being created are having a task spawned off that does a yum metadata publish. At this point the repos are empty so this does not take very long (less than a second), but it can cause many tasks to be spawned. Version-Release number of selected component (if applicable): 6.1.1 How reproducible: Always Steps to Reproduce: 1. Create a product with 5 repos. 2. Add the product to a sync plan 3. Create a content view and add all 5 repos. 4. Publish the content view. Actual results: a) within the 'publish' task of the dynflow console you'll see 5 'UpdateSchedule' tasks. b) Within Monitor > Tasks you will see 5 MetadataGenerate tasks. Expected results: You should see neither a) nor b) Additional info: --- Additional comment from Justin Sherrill on 2015-09-04 10:14:29 EDT --- Since this does not seem to cause any actual performance issues, i'm not sure this needs to be a zstream. --- Additional comment from RHEL Product and Program Management on 2015-10-16 11:53:38 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 Bryan Kearney on 2016-07-08 16:47:47 EDT --- Per 6.3 planning, moving out non acked bugs to the backlog --- Additional comment from RHEL Product and Program Management on 2016-07-08 17:31:13 EDT --- This bug report previously had all acks and release flag approved. However since at least one of its acks has been changed, the release flag has been reset to ? by the bugbot (pm-rhel). The ack needs to become approved before the release flag can become approved again. --- Additional comment from Brad Buckingham on 2016-08-24 16:13:28 EDT --- Created redmine issue http://projects.theforeman.org/issues/16274 from this bug --- Additional comment from Bryan Kearney on 2016-09-14 16:09:59 EDT --- Upstream bug assigned to inecas --- Additional comment from Bryan Kearney on 2016-09-14 16:10:02 EDT --- Upstream bug assigned to inecas --- Additional comment from Bryan Kearney on 2016-09-20 20:09:19 EDT --- Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16499 has been resolved. --- Additional comment from Bryan Kearney on 2016-10-03 12:30:57 EDT --- I am moving all bugs which have been addressed in either katello 3.2 or foreman 13.0 and 13.1 to ON_QA. These bugs have been delivered in the first 3 snaps. --- Additional comment from Bryan Kearney on 2016-10-03 12:54:32 EDT --- Moving all bugs which are fixed in Katello 3.2 to ON_QA for 6.3. These were delivered in the initial snaps of 6.3.
Verified on Satellite 6.3 SNAP 11: satellite-6.3.0-16.0.beta.el7sat.noarch , tfm-rubygem-katello-3.4.4-1.el7sat.noarch Tested using scenario described by the original solution provided in 6.2.z (bug 1372073). Observed that no unnecessary steps were planned/executed for a CV published containing 6 repositories all included as part of a sync plan.
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-2018:0336
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-2018:0336