Bug 857274 - Promotion stuck in "applying" status
Summary: Promotion stuck in "applying" status
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Content Management
Version: 6.0.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: Unspecified
Assignee: David Davis
QA Contact: Og Maciel
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-14 00:52 UTC by Og Maciel
Modified: 2019-09-26 15:51 UTC (History)
4 users (show)

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.
Clone Of:
Environment:
Last Closed: 2012-12-04 19:52:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
reproducer.sh (2.18 KB, application/x-shellscript)
2012-09-14 00:52 UTC, Og Maciel
no flags Details
Screenshot (8.76 KB, image/png)
2012-09-14 00:53 UTC, Og Maciel
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:1543 0 normal SHIPPED_LIVE Important: CloudForms System Engine 1.1 update 2012-12-05 00:39:57 UTC

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


Note You need to log in before you can comment on or make changes to this bug.