Bug 1648506

Summary: virt-who is failing when pushing the information to the Satellite Server
Product: Red Hat Satellite Reporter: Waldirio M Pinheiro <wpinheir>
Component: Subscriptions - virt-whoAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED ERRATA QA Contact: Eko <hsun>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.3.4CC: aeladawy, arahaman, bcourt, bkearney, cmarinea, dcarmich, gapatil, jalviso, jbhatia, jmcdonald, khowell, knakai, ktordeur, mmccune, ninooke, phess, pwaghmar, rbertolj, satellite6-bugs, smane, vgunasek, vmeghana, vwariyal, wpinheir, wpoteat, yoliynyk, yuefliu
Target Milestone: 6.5.0Keywords: PrioBumpGSS, Triaged
Target Release: Unused   
Hardware: All   
OS: All   
Fixed In Version: candlepin-2.4.10-1, candlepin-2.5.11-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1651651 1684693 (view as bug list) Environment:
Last Closed: 2019-05-14 12:38:41 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:
Bug Depends On: 1670522    
Bug Blocks: 1651651, 1651710, 1651713    
Description Flags
rhsm.log none

Description Waldirio 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):

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

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:

Comment 3 Barnaby Court 2018-11-10 21:16:44 UTC
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.

Comment 7 Kevin Howell 2018-11-29 15:27:40 UTC
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 11 Waldirio 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


Thank you.

Best Regards
Waldirio M Pinheiro | Senior Software Maintenance Engineer

Comment 13 Kevin Howell 2019-01-04 19:26:26 UTC
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).

Comment 28 Mike McCune 2019-03-01 22:16:34 UTC
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.

Comment 30 yuefliu 2019-03-12 05:31:38 UTC
Created attachment 1543107 [details]

Comment 32 Ahmed Eladawy 2019-03-15 11:26:16 UTC

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.


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

Comment 36 errata-xmlrpc 2019-05-14 12:38:41 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.