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.
Description of problem:
In case a hypervisor is registered as a Host and is running virt-who, a task to update the Host can fail on acquired lock. The reason is, both rhsmcertd-worker AND virt-who can fire "PUT /rhsm/consumers/${UUID}" requests concurrently and independently, what leads to concurrent Actions::Katello::Host::Update tasks where either of them fails with "Required lock is already taken by other running tasks" error.
We should handle this better in our API, that e.g. should handle the 2nd request, wait till the 1st is completed and then continue in the 2nd one.
Version-Release number of selected component (if applicable):
Sat 6.3, expected in 6.4 as well.
How reproducible:
100% with some effort / proper timing
Steps to Reproduce:
1. Have a hypervisor registered as a Host, with virt-who installed & configured
2. Populate or update some host's facts, just to have Host update crunching the facts longer.
3. Enable rhsm debugs and restart rhsmcertd service
4. Check rhsm logs to spot time when "PUT /rhsm/consumers/${UUID}" is triggered.
5. At that time, run virt-who -o.
6. After a while, check for status of 2 Host update tasks for this Host.
Actual results:
2nd Host update fails with "Required lock is already taken by other running tasks" error.
Expected results:
2nd Host update task proceeds well.
Additional info:
Description of problem: In case a hypervisor is registered as a Host and is running virt-who, a task to update the Host can fail on acquired lock. The reason is, both rhsmcertd-worker AND virt-who can fire "PUT /rhsm/consumers/${UUID}" requests concurrently and independently, what leads to concurrent Actions::Katello::Host::Update tasks where either of them fails with "Required lock is already taken by other running tasks" error. We should handle this better in our API, that e.g. should handle the 2nd request, wait till the 1st is completed and then continue in the 2nd one. Version-Release number of selected component (if applicable): Sat 6.3, expected in 6.4 as well. How reproducible: 100% with some effort / proper timing Steps to Reproduce: 1. Have a hypervisor registered as a Host, with virt-who installed & configured 2. Populate or update some host's facts, just to have Host update crunching the facts longer. 3. Enable rhsm debugs and restart rhsmcertd service 4. Check rhsm logs to spot time when "PUT /rhsm/consumers/${UUID}" is triggered. 5. At that time, run virt-who -o. 6. After a while, check for status of 2 Host update tasks for this Host. Actual results: 2nd Host update fails with "Required lock is already taken by other running tasks" error. Expected results: 2nd Host update task proceeds well. Additional info: