On 7/24/2019 9:34 AM, Matt Riedemann wrote:
Massimo - just to confirm, your [libvirt]/virt_type is "kvm" rather than "qemu" correct? If so, then yeah what Melanie found is the problem and was regression in behavior for the ImagePropertiesFilter in Rocky and there should be a fix to the docs and likely a release note - though the release note is tricky since the regression was introduced in Rocky.
Note that the glance description of the hypervisor_type property is also wrong: https://docs.openstack.org/glance/latest/admin/useful-image-properties.html "The hypervisor type. Note that qemu is used for both QEMU and KVM hypervisor types." Given https://review.opendev.org/#/c/531328/ was abandoned, if the API is still showing QEMU for the hypervisor type (which Massimo confirmed it is) even though the node is configured with virt_type=kvm and that's what the ImagePropertiesFilter is going to use, I think we'd be justified in reverting https://review.opendev.org/#/c/531347/ since it's totally confusing to operators if the API is showing the hypervisor_type as QEMU but the scheduler is filtering on "kvm". We can change the docs but that feels like papering over the issue to me. What would the docs say? Something like, "Since the 18.0.0 Rocky release, the hypervisor_type value for libvirt nodes should match the configured [libvirt]/virt_type value"? That won't fix any existing images with their properties embedded in an instance's system_metadata which could prevent you from being able to migrate those instances anywhere during the upgrade - you'd have to essentially do some database surgery in the instance_system_metadata table to fix the image_hypervisor_type value to match whatever the virt_type value is on that node. Alternatively we could try to put some targeted compat code in the ImagePropertiesFilter where if the hypervisor_type is QEMU/qemu but the node is reporting kvm, we let it slide and accept that host? -- Thanks, Matt