Project

General

Profile

Bug #30826

Hypervisors upload fails with duplicate UUIDs

Added by Jonathon Turel about 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Category:
Hosts
Target version:
Difficulty:
Triaged:
Yes
Bugzilla link:
Fixed in Releases:
Found in Releases:

Description

b'Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1812904 \n\n+++ This bug was initially created as a clone of Bug #1777440 +++\n\n*Description of problem:*\n\'Hypervisors\' task fails with \'undefined method `[]\' for nil:NilClass\' error when \'virt-who-0.24.7-1.el7.noarch\' is being used. This is not reproducible with virt-who-0.22.5-1.el7.noarch.\n\n### TEST with \'virt-who-0.24.7-1.el7.noarch\' ###\n\n# rpm qa | grep -e virt-who -e satellite-6\n~~~\nvirt-who-0.24.7-1.el7.noarch\nsatellite-6.5.2.1-1.el7sat.noarch\n~~~\n\n Config file:\n\n# cat /etc/virt-who.d/02499113.conf\n~~~\n02499113\ntype=fake\nfile=/etc/virt-who.d/json/02499113.json\nis_hypervisor=True\nowner=Default_Organization\nenv=Library\nhypervisor_id=hostname\nrhsm_hostname=jsenkyri-sat64.sysmgmt.lan\nrhsm_username=admin\nrhsm_password=XXX\nrhsm_prefix=/rhsm\n~~~\n\n- Mappings being used: attached \'02499113.json\' file\n\n- First virt-who run ends in success:\n~~~\nId: 05359f6c-5a89-4d97-9670-f7d9461cce16\nLabel: Actions::Katello::Host::Hypervisors\nStatus: stopped\nResult: success\nStarted at: 2019-11-27 13:17:36 UTC\nEnded at: 2019-11-27 13:21:57 UTC \n~~\n\n- Second (and any future) virt-who run with the same config and same mappings ends with error:\n~~~\nId: 46616c49-4709-4232-948c-e8939cd8437e\nLabel: Actions::Katello::Host::Hypervisors\nStatus: stopped\nResult: warning\nStarted at: 2019-11-27 13:31:31 UTC\nEnded at: 2019-11-27 13:31:37 UTC\n~~~\n\n~~~\nNoMethodError\nundefined method `[]\' for nil:NilClass\n~~~\n\n____________________________\n\n\n### TEST with \'virt-who-0.22.5-1.el7.noarch\' ###\n\n# rpm qa | grep -e virt-who -e satellite-6\n~~~\nvirt-who-0.22.5-1.el7.noarch\nsatellite-6.5.2.1-1.el7sat.noarch\n~~~\n\n Config file:\n\n# cat /etc/virt-who.d/02499113.conf\n~~~\n02499113\ntype=fake\nfile=/etc/virt-who.d/json/02499113-older-virt-who.json\nis_hypervisor=True\nowner=Default_Organization\nenv=Library\nhypervisor_id=hostname\nrhsm_hostname=jsenkyri-sat64.sysmgmt.lan\nrhsm_username=admin\nrhsm_password=XXX\nrhsm_prefix=/rhsm\n~~~\n\n- Mappings being used: attached \'02499113-older-virt-who.json\' file\n\n- First any any other future virt-who run ends with success:\n~~~\nId: 78e7e97a-eada-410b-ad80-4f91cc700d43\nLabel: Actions::Katello::Host::Hypervisors\nStatus: stopped\nResult: success\nStarted at: 2019-11-27 14:50:01 UTC\nEnded at: 2019-11-27 14:52:09 UTC\n~~~\n\n____________________________\n\n*Additional info:*\n- This is happening because \'virt-who-0.24.7-1\' reports duplicate \'dmi.system.uuid\' for some of the hypervisors:\n\n# grep \'20202020-2020-2020-2020-202020202020\' 0.24.7-1.json\n~~~ \n "dmi.system.uuid": "20202020-2020-2020-2020-202020202020", \n "dmi.system.uuid": "20202020-2020-2020-2020-202020202020", \n "dmi.system.uuid": "20202020-2020-2020-2020-202020202020", \n "dmi.system.uuid": "20202020-2020-2020-2020-202020202020", \n "dmi.system.uuid": "20202020-2020-2020-2020-202020202020", \n "dmi.system.uuid": "20202020-2020-2020-2020-202020202020", \n~~~\n\n\n- \'virt-who-0.22.5-1\' doesn\'t do that:\n\n# grep \'20202020-2020-2020-2020-202020202020\' 0.22.5-1.json\n~~~\n<no results>\n~~~\n\n- \'virt-who-0.24.7-1\' reports "dmi.system.uuid" for every hypervisor:\n\n# grep dmi.system.uuid 0.24.7-1.json | wc l\n~~~\n831\n~~~\n\n \'virt-who-0.22.5-1\' reports "dmi.system.uuid" for only a part of them:\n\n# grep dmi.system.uuid 0.22.5-1.json | wc l\n~~~\n64\n~~~\n\n____________________________\n\n\nIt\'s clear that the root cause of this issue are the duplicate hypervisor uuids which is something that needs to be fixed on the system level (in this case those are ESX hosts). That being said can we somehow instruct virt-who to not pass \'dmi.system.uuid\' to Satellite? Or is the only current workaround to just stay on the older virt-who version until the duplicate uuids are gone?\n\nThanks & Kind regards,\nJan\n\n-- Additional comment from RHEL Program Management on 2019-11-27 15:30:46 UTC ---\n\nSince this bug report was entered in Red Hat Bugzilla, the \'sat-backlog\' flag has been set to ? to ensure that it is properly evaluated for release.\n\n--- Additional comment from RHEL Program Management on 2019-11-27 15:30:46 UTC ---\n\nSince this issue was entered in Red Hat Bugzilla, the pm_ack has been set to + automatically for the next planned release.\n\n--- Additional comment from Jan Senkyrik on 2019-11-27 15:36:05 UTC ---\n\n\n\n--- Additional comment from Jan Senkyrik on 2019-11-27 15:36:55 UTC ---\n\n\n\n--- Additional comment from Jan Senkyrik on 2019-11-27 15:37:50 UTC ---\n\n\n\n--- Additional comment from Jan Senkyrik on 2019-11-27 15:38:36 UTC ---\n\n\n\n--- Additional comment from Brad Buckingham on 2019-12-10 18:38:54 UTC ---\n\nJonathon, \n\nWould this be addressed by the changes introduced in Satellite 6.6?\n\n--- Additional comment from Jonathon Turel on 2019-12-10 20:13:14 UTC ---\n\nThis looks like a different problem. I saw that we fixed (identical stack trace) a similar problem in 6.5.0 due to how we were checking the candlepin job status: https://bugzilla.redhat.com/show_bug.cgi?id=1637042 however it was recently updated with another BZ filed that resembles this one: https://bugzilla.redhat.com/show_bug.cgi?id=1769680\n\nAssuming that we are checking the job status correctly per the fix in bz #1637042 it gives the impression that the result of the job from the candlepin API is not in the format we are expecting (or missing altogether) which means it could have failed in an unexpected way on that end. There is a candlepin log in bz #1769680 which might be a clue.\n\n--- Additional comment from William Poteat on 2019-12-16 19:51:15 UTC ---\n\nThe systems that share the same dmi.system.uuid can be updated with a custom fact file to override the value and make them unique.\n\nThe attached PR, which is available in the current Candlepin 2.11, will defeat the matching on this attribute altogether. It will also allow the duplicate entries for systems to return if the user changes the hostname or has a host that checks in as a standard consumer.\n\n--- Additional comment from William Poteat on 2019-12-16 19:54:25 UTC ---\n\nThe first solution in Comment 9 does not require any software updates.\n\nThe second is slated for Sat 6.7. If it needs to be put in earlier versions, please say so.\n\n--- Additional comment from Marek Hulan on 2020-03-06 08:52:16 UTC ---\n\nWilliam, could this be cherry-picked to 6.6? Right now the only workaround is to downgrade to older version of virt-who. The version present in RHEL is already newer and does not work with any released version of Satellite. I\'m not sure which all hypervisors are affected, but feels pretty bad even if that was just one.'

Associated revisions

Revision 59210c07 (diff)
Added by Jonathon Turel about 1 month ago

Fixes #30826 - Handle Hypervisors report containing duplicate UUIDs

History

#1 Updated by The Foreman Bot about 2 months ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/Katello/katello/pull/8942 added

#2 Updated by Jonathon Turel about 2 months ago

  • Target version set to Katello 3.18.0
  • Subject changed from Hypervisors upload fails with duplicate UUIDs to Hypervisors upload fails with duplicate UUIDs

#3 Updated by The Foreman Bot about 1 month ago

  • Fixed in Releases Katello 4.0.0 added

#4 Updated by Jonathon Turel about 1 month ago

  • Status changed from Ready For Testing to Closed

#5 Updated by James Jeffers about 1 month ago

  • Triaged changed from No to Yes

Also available in: Atom PDF