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.
DescriptionWaldirio M Pinheiro
2018-11-10 02:11:34 UTC
Description of problem:
During the process to push the information to the SAtellite, virt-who is failing. We were able to map 3 of 7 files failing, then after define just one file per time, we can see the issue below.
---
2018-11-08 17:44:09,295 [virtwho.destination_7946341179911625283 WARNING] MainProcess(126711):Thread-3 @subscriptionmanager.py:check_report_state:365 - Job status report without resultData: {u'finishTime': None, u'targetType': u'owner', u'updated': u'2018-11-08T22:43:54+0000', u'group': u'async group', u'created': u'2018-11-08T22:43:54+0000', u'resultData': None, u'statusPath': u'/jobs/hypervisor_update_ab1b6546-02d3-4b99-be98-48e37aaac5a4', u'targetId': u'RJF', u'principalName': u'foreman_admin', u'state': u'FAILED', u'done': True, u'result': u'No migration is pending', u'startTime': u'2018-11-08T22:43:54+0000', u'ownerId': u'RJF', u'id': u'hypervisor_update_ab1b6546-02d3-4b99-be98-48e37aaac5a4', u'correlationId': u'd2ad3396'}
---
Version-Release number of selected component (if applicable):
6.3.5
How reproducible:
Only on the customer env
Steps to Reproduce:
1. Configure the virt-who files *customer did via webUI helper
2. virt-who -o
3.
Actual results:
Still failing for 3 files, if we define only one file, the issue persist.
Expected results:
Process without error and push the information to the Satellite Server
Additional info:
Waldirio, The first thing do do would be to look through the foreman & candlepin log files. In the json you originially attached is both a job id & a correlation id that can be used to grep the logs to see what happened. Please check there first and let us know what you find.
Waldirio, let's use this BZ to tackle the "No migration is pending" issue. Let's handle the "Link length exceeded" separately with the Katello team (the queries Katello creates should be modified to not cause "limit length exceeded").
Comment 11Waldirio M Pinheiro
2018-11-30 21:12:42 UTC
(In reply to Kevin Howell from comment #7)
> Waldirio, let's use this BZ to tackle the "No migration is pending" issue.
> Let's handle the "Link length exceeded" separately with the Katello team
> (the queries Katello creates should be modified to not cause "limit length
> exceeded").
I agree. Just to keep on track
https://bugzilla.redhat.com/show_bug.cgi?id=1651774
Thank you.
Best Regards
--
Waldirio M Pinheiro | Senior Software Maintenance Engineer
To summarize: there is a scenario which is not currently accounted for in Candlepin logic. If encountered, currently Candlepin fails the hypervisor check-in (virt-who check-in) and logs java.lang.IllegalStateException: No migration is pending. After the fix lands, we'll handle the scenario properly.
Also seen in log output is this bug are messages about link limit exceeded, which are misleading, but not actual issues (these messages are to be handled in bug 1651774).
This bug was cloned and is still going to be included in the 6.4.3 release. It no longer has the sat-6.4.z+ flag and 6.4.3 Target Milestone Set which are now on the 6.4.z cloned bug. Please see the Clones field to track the progress of this bug in the 6.4.3 release.
Hello,
on case 02283804 the following WARN is still existing after applying the patch .
2019-03-15 10:30:41,058 [thread=http-bio-8443-exec-9] [req=5619183d-fb3b-4a9f-add4-3bf43917d3ec, org=, csid=] WARN org.candlepin.common.resteasy.filter.LinkHeaderResponseFilter - Link length exceeded maximum length (1024). Link headers will be omitted from this response.
candlepin-2.4.12-1.el7.noarch
tfm-rubygem-katello-3.7.0.46-1.el7sat.noarch
satellite-6.4.2-2.el7sat.noarch
However Hypervisors are successful after applying the patch :
Actions::Katello::Host::Hypervisors 2019-03-15 09:30:12 2019-03-15 09:31:51 stopped success
Actions::Katello::Host::Hypervisors 2019-03-15 09:27:27 2019-03-15 09:27:28 stopped success
Actions::Katello::Host::Hypervisors 2019-03-15 09:12:50 2019-03-15 09:14:38 stopped success
Actions::Katello::Host::Hypervisors 2019-03-15 09:10:29 2019-03-15 09:10:31 stopped success
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-2019:1222
Description of problem: During the process to push the information to the SAtellite, virt-who is failing. We were able to map 3 of 7 files failing, then after define just one file per time, we can see the issue below. --- 2018-11-08 17:44:09,295 [virtwho.destination_7946341179911625283 WARNING] MainProcess(126711):Thread-3 @subscriptionmanager.py:check_report_state:365 - Job status report without resultData: {u'finishTime': None, u'targetType': u'owner', u'updated': u'2018-11-08T22:43:54+0000', u'group': u'async group', u'created': u'2018-11-08T22:43:54+0000', u'resultData': None, u'statusPath': u'/jobs/hypervisor_update_ab1b6546-02d3-4b99-be98-48e37aaac5a4', u'targetId': u'RJF', u'principalName': u'foreman_admin', u'state': u'FAILED', u'done': True, u'result': u'No migration is pending', u'startTime': u'2018-11-08T22:43:54+0000', u'ownerId': u'RJF', u'id': u'hypervisor_update_ab1b6546-02d3-4b99-be98-48e37aaac5a4', u'correlationId': u'd2ad3396'} --- Version-Release number of selected component (if applicable): 6.3.5 How reproducible: Only on the customer env Steps to Reproduce: 1. Configure the virt-who files *customer did via webUI helper 2. virt-who -o 3. Actual results: Still failing for 3 files, if we define only one file, the issue persist. Expected results: Process without error and push the information to the Satellite Server Additional info: