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.

Bug 857274

Summary: Promotion stuck in "applying" status
Product: Red Hat Satellite Reporter: Og Maciel <omaciel>
Component: Content ManagementAssignee: David Davis <daviddavis>
Status: CLOSED ERRATA QA Contact: Og Maciel <omaciel>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.0.1CC: achan, asettle, inecas, mmccune
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Random promotional changesets were not completing the promotion process, seemingly stuck on the "applying" status. Various code changes has fixed this issue and users are now able to properly promote promotion changesets.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-04 19:52:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
reproducer.sh
none
Screenshot none

Description Og Maciel 2012-09-14 00:52:34 UTC
Created attachment 612699 [details]
reproducer.sh

Description of problem:

Using the web ui only I have gone through the process of creating 2 different providers: one containing 4 different custom yum repos, and the other containing epel only. Firstly, I synced all 4 repositories from the first provider, created a promotion changeset (Library > DEV) named promote-20120913-1 and reviewed it but did not promote right away. Then I synced the epel repository from the second provider, and also created a new promotion changeset (Library > DEV) named promote-20120913-2 and reviewed it but did not promote it either. Then, I promoted changeset promote-20120913-1 but the web ui says that it is still being applied. Several hours have passed, I have switched tabs and gone back to the Promotions page, but it still shows as being in the process of being applied.

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


How reproducible:


Steps to Reproduce:
1. Follow the attached CLI script to *manually* create the organization, providers, products and repos.
2. Synchronize the product with 4 repositories
3. Create a promotion changeset, add the product with 4 repositories, review it (i.e. "lock" it) but do not promote it
4. Synchronize the product with 1 repository (epel)
5. Create a second promotion changeset, and add the product with 1 repository, review it (i.e. "lock" it) but do not promote it
6. Select the first changeset and click the Promote button
  
Actual results:

The promotion doesn't seem to end, and it keeps displaying the status "Applying" even after several hours later. A quick look at logs does not show any sign that the promotion took place.

Expected results:


Additional info:

Comment 2 Og Maciel 2012-09-14 00:53:57 UTC
Created attachment 612700 [details]
Screenshot

Comment 5 Mike McCune 2012-09-14 19:12:55 UTC
Going to have David take a look at this

Comment 6 David Davis 2012-09-15 11:46:24 UTC
Og, were you ever able to start katello jobs? Btw, are katello jobs built on top of delayed_job? In other words, does running delayed_job start katello jobs? Thanks!

Comment 7 David Davis 2012-09-15 14:07:16 UTC
After looking into the code, I see that katello-jobs is a service that uses delayed_job. I was able to start and stop it locally as well given the nightly code. Og, you have an ssh accessible box where this is running right? Do you think you could give me access? Thank you!

Comment 8 Og Maciel 2012-09-15 15:12:37 UTC
Hey Davis! Unfortunately I no longer have that box around anymore, but I did try to restart katello-jobs when you were sitting with me and the service never started. As a matter of fact, the load avg got higher than 20 and then I rebooted the system. Then, and only then, katello-jobs started but the changeset was still sitting there with the same "applying" message.

Comment 9 David Davis 2012-09-15 15:34:01 UTC
Cool, thanks Og. I'll take a look into it.

Comment 10 David Davis 2012-09-17 20:26:47 UTC
After some initial testing, I haven't been able to reproduce. Each time I've promoted a changeset it's gone from Applying to Applied. I've been following the script and steps to reproduce for the most part. I think it may either be that the differences account for the bug or perhaps the bug exists on the system-engine code but has been fixed in katello. I'll look into this more tomorrow.

Comment 11 David Davis 2012-09-18 15:59:22 UTC
Tried recreating the bug in katello and both promotions were applied for me.

Comment 18 Og Maciel 2012-09-25 21:09:28 UTC
Verified using:

* candlepin-0.7.8-1.el6cf.noarch
* candlepin-selinux-0.7.8-1.el6cf.noarch
* candlepin-tomcat6-0.7.8-1.el6cf.noarch
* katello-1.1.12-9.el6cf.noarch
* katello-all-1.1.12-9.el6cf.noarch
* katello-candlepin-cert-key-pair-1.0-1.noarch
* katello-certs-tools-1.1.8-1.el6cf.noarch
* katello-cli-1.1.8-5.el6cf.noarch
* katello-cli-common-1.1.8-5.el6cf.noarch
* katello-common-1.1.12-9.el6cf.noarch
* katello-configure-1.1.9-4.el6cf.noarch
* katello-glue-candlepin-1.1.12-9.el6cf.noarch
* katello-glue-pulp-1.1.12-9.el6cf.noarch
* katello-qpid-broker-key-pair-1.0-1.noarch
* katello-qpid-client-key-pair-1.0-1.noarch
* katello-selinux-1.1.1-1.el6cf.noarch
* pulp-1.1.12-1.el6cf.noarch
* pulp-common-1.1.12-1.el6cf.noarch
* pulp-selinux-server-1.1.12-1.el6cf.noarch

Comment 20 errata-xmlrpc 2012-12-04 19:52:52 UTC
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.

http://rhn.redhat.com/errata/RHSA-2012-1543.html

Comment 21 Mike McCune 2013-08-16 18:04:26 UTC
getting rid of 6.0.0 version since that doesn't exist