René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"VMware: VM ingestion broken in case of dynamically handled hypervisor/guest OS versions.","articleBody":"ACS 4.19 RC1\r\n\r\nVMware ingestion is broken when testing with VMware 8.0.0.2as the hypervisor and Rocky Linux (8 or 9) - this is a consequence of changes implemented in https://github.com/apache/cloudstack/pull/7380:\r\n\r\n- if no record for 8.0.0.2 in the hypervisor_capabilities table, then use \"capabilities\" of the \"parent\" version which is VMware 8.0; \r\n- if no records in the guest_os_hypervisor table, then use the records/mappings of the \"parent\" version - from 8.0\r\n- this all works fine during VM deployment\r\n- this does not work during VMware ingestion, where we do reverse-mapping, and code seems to look for a DB record for \"rockylinux_64Guest\" for version 8.0.0.2 in the guest_os_hypervisor table - and this record does not exist\r\n\r\nThe logic of \"mapping minor version guest OS mappings, if missing, to a parent version mappings\" - sounds fine, as long as:\r\n\r\n- It's supported by all ACS features/code where we try to use guest OS hypervisor mappings (this now includes VMware VM ingestion that needs to be fixed, but there might be other places)\r\n- there is detailed logging similar to \"The guest OS mappings for XXX was not found for the hypervisor version YYYYY (8.0.0.2), looking for parent version mappings (8.0), found, using that mapping etc\" - something similar to this, needs to be very verbose, otherwise troubleshooting will be impossible.\r\n\r\nFor the hypervisor capabilities, I would propose the following:\r\n\r\n- Revert the logic of dynamically \"assuming\" that the minor version has the same capabilities as the major version (in fugure, VMware e.g. 8.5 version will certainly NOT have the same capabilities as the 8.0 version, it would have more capabilities) - so revert the code and recreated the needed DB records in the hypervisor_capabilities table\r\n- Worst case, even though it's a bad solution - leave it as it is, but add a loooot of logging, similar to the guest OS mappings logging (not found this, using that version capabilities)\r\n","author":{"url":"https://github.com/andrijapanicsb","@type":"Person","name":"andrijapanicsb"},"datePublished":"2023-12-28T12:17:38.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/8412/cloudstack/issues/8412"}