Open Stack

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