Revert "[libvirt] Filter hypervisor_type by virt_type"
This reverts commit eaa766ee2093c24fd61c61e52f46bdd9ff9e93d2.
The change regressed the behavior of the ImagePropertiesFilter
because existing images with hypervisor_type=QEMU, which would
match what is reported for hypervisor_type in the API for both
qemu/kvm virt_type nodes, will now get filtered out for hosts
where the configured virt_type is kvm.
Note that both the ImagePropertiesFilter docs [1] and
hypervisor_type image property docs [2] mention that for both
qemu and kvm nodes the value to use is qemu since that is the
actual hypervisor.
Presumably the change was made for a deployment with some
hosts configured with virt_type=qemu and other hosts configured
with virt_type=kvm and there were separate images with
hypervisor_type=qemu and hypervisor_type=kvm to match those hosts
for scheduler filter, but as noted this was a regression in
behavior for something that could have been achieved using
host aggregates and the AggregateImagePropertiesIsolation filter.
We could even use traits and a placement request pre-filter these
days for a more modern approach.
Also, since the API continues to report hypervisor_type=QEMU it's
doubly confusing for operators to have to configure their images
to use hypervisor_type=kvm (despite the docs).
And finally, any existing instances which have hypervisor_type=qemu
embedded in their RequestSpec can no longer be migrated to kvm
hosts without manually fixing the entries in the request_specs
table in the API DB.
Note that this is not a clean revert because of change
I5d95bd50279a6bf903a5793ad5f3ae9d06f085f4 made in Stein.
Reviewed: https:/ /review. opendev. org/672559 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=743dc083bb5 628554d9abfa826 65738233ed47e9
Committed: https:/
Submitter: Zuul
Branch: master
commit 743dc083bb56285 54d9abfa8266573 8233ed47e9
Author: Matt Riedemann <email address hidden>
Date: Wed Jul 24 16:22:52 2019 +0000
Revert "[libvirt] Filter hypervisor_type by virt_type"
This reverts commit eaa766ee2093c24 fd61c61e52f46bd d9ff9e93d2.
The change regressed the behavior of the ImageProperties Filter type=QEMU, which would
because existing images with hypervisor_
match what is reported for hypervisor_type in the API for both
qemu/kvm virt_type nodes, will now get filtered out for hosts
where the configured virt_type is kvm.
Note that both the ImageProperties Filter docs [1] and
hypervisor_type image property docs [2] mention that for both
qemu and kvm nodes the value to use is qemu since that is the
actual hypervisor.
Presumably the change was made for a deployment with some type=qemu and hypervisor_type=kvm to match those hosts ropertiesIsolat ion filter.
hosts configured with virt_type=qemu and other hosts configured
with virt_type=kvm and there were separate images with
hypervisor_
for scheduler filter, but as noted this was a regression in
behavior for something that could have been achieved using
host aggregates and the AggregateImageP
We could even use traits and a placement request pre-filter these
days for a more modern approach.
Also, since the API continues to report hypervisor_ type=QEMU it's
doubly confusing for operators to have to configure their images
to use hypervisor_type=kvm (despite the docs).
And finally, any existing instances which have hypervisor_ type=qemu
embedded in their RequestSpec can no longer be migrated to kvm
hosts without manually fixing the entries in the request_specs
table in the API DB.
Note that this is not a clean revert because of change 9a6bf903a5793ad 5f3ae9d06f085f4 made in Stein.
I5d95bd5027
[1] https:/ /docs.openstack .org/nova/ latest/ admin/configura tion/schedulers .html#imageprop ertiesfilter /docs.openstack .org/glance/ latest/ admin/useful- image-propertie s.html
[2] https:/
Change-Id: I7d761dc269f8c1 2c4a76ba14201cc dd82a04d01d
Closes-Bug: #1837756