Bug 1458674

Summary:	"KeyError: 'guestIds'" occurs after trigger guest when virt-who run against stage candlepin 2.0
Product:	Red Hat Enterprise Linux 7	Reporter:	yuefliu <yuefliu>
Component:	virt-who	Assignee:	Chris Snyder <csnyder>
Status:	CLOSED ERRATA	QA Contact:	Eko <hsun>
Severity:	medium	Docs Contact:
Priority:	high
Version:	7.4	CC:	cdonnell, csnyder, hasuzuki, hsun, jherrman, khowell, ktordeur, mjia, rjerrido, wpoteat, yanpliu
Target Milestone:	rc	Keywords:	Triaged, ZStream
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Previously, the virt-who service expected an outdated data format from the hypervisor check-ins. Consequently, virt-who in some cases failed to send the guest-hypervisor mappings and logged a "KeyError: 'guestIds'" message. The data format expected by virt-who has been updated, which prevents the described problem from occurring.	Story Points:	---
Clone Of:
Clones:	1462942 1463996 1464129 1464133 1469737 (view as bug list)		Environment:
Last Closed:	2018-04-10 16:19:53 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:
Bug Depends On:
Bug Blocks:	1462942, 1463996, 1464129, 1464133, 1469737

Comment 4 Eko 2017-06-08 03:28:23 UTC

Hi Chris,
Most of our automation cases depend on the H/g message in rhsm.log, we need to check:
 - how many guests are listed for this hypervisors? make sure the dependence of H/g is expected.
 - what is the guest's state if poweron/poeroff/resume?

so if the guest info removed from rhsm.log, we can't know which guest has the poweron/poeroff/resume event, and also don't know the guest state is right or not?

is it possible that show the H/g info in rhsm.log before send to candlepin?
 - virt-who list the H/g info firstly
 - and then start to send
 - return send state, success or not

Comment 6 Eko 2017-06-09 01:27:38 UTC

ok, I absolutely agree with you, move it to 7.5, thanks.

Comment 7 Eko 2017-06-09 07:08:14 UTC

Hi Chris,
I have run the regression test for virt-who-0.17-12.el7_3 z stream build with stage candlepin2.0, 
the test results made me a little afraid, if KeyError: 'guestIds' arise, virt-who will be terminated. 

I suggest we remove the codes from virtwho/manager/subscriptionmanager/subscriptionmanager.py for virt-who-0.17-12.el7_3 and virt-who-0.19-5.el7 both packages.

As you said, these codes only used to log the report state, from my test result, it will not influence the h/g json info in rhsm.log when I removed the below code segment: 

            #for updated in resultData.get('updated', []):
            #   guests = [x['guestId'] for x in updated['guestIds']]
            #   self.logger.debug("Updated host %s with guests: [%s]",
            #                     updated['uuid'],
            #                     ", ".join(guests))
            #for created in resultData.get('created', []):
            #    guests = [x['guestId'] for x in created['guestIds']]
            #    self.logger.debug("Created host: %s with guests: [%s]",
            #                      created['uuid'],
            #                      ", ".join(guests))

Comment 10 Eko 2017-06-12 08:02:58 UTC

Hi Chris,

Thanks for the clear explanation, I agree with you, move it to RHEL7.5

Comment 11 Chris Snyder 2017-06-13 02:20:13 UTC

Adding a PR with the removal of the use of the guestIds key against upstream master.

We can proceed with fixing this additional places once we have this fix approved and tested.

Eko,

Could I please get a qa_ack on this bug. Thank you!


Cheers,
Chris

Comment 12 Chris Snyder 2017-06-19 18:22:39 UTC

This has been fixed in virt-who upstream and will be pulled into the first build for RHEL 7.5. Moving this to MODIFIED.

Comment 13 Kevin Howell 2017-06-26 14:45:40 UTC

*** Bug 1463996 has been marked as a duplicate of this bug. ***

Comment 15 yuefliu 2017-07-31 07:24:28 UTC

Have fixed the clone Bug 1469737 with virt-who-0.19-6.el7_4.noarch for rhel7.4.z, and will verify it in the first build for RHEL 7.5.

Comment 18 yuefliu 2017-12-05 08:37:32 UTC

Verified the bug with virt-who-0.21.1-1.el7.noarch, no the issue reproduce.

Comment 21 errata-xmlrpc 2018-04-10 16:19:53 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.

https://access.redhat.com/errata/RHEA-2018:0895