This reverts commit eaa766ee20.
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.
[1] https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#imagepropertiesfilter
[2] https://docs.openstack.org/glance/latest/admin/useful-image-properties.html
Change-Id: I7d761dc269f8c12c4a76ba14201ccdd82a04d01d
Closes-Bug: #1837756
As we now provide the original source bdms during rollback we can also
use them to reset any volume attachment ids to the ids used by the
source compute host.
Change-Id: Ibe9215c07a1ee00e0e121c69bcf7ee1b1b80fae0
With the removal of the Core, Ram and Disk filters in change
I8a0d332877fbb9794700081e7954f2501b7e7c09, there's now only a single
caller for the 'estimate_instance_overhead' function. This call results
in the 'memory_mb_used', 'local_gb_used', 'vcpus_used', 'free_ram_mb'
and 'free_disk_gb' fields of a compute nodes 'ComputeNode' object being
modified when calculating usage as part of the resource tracker to
include driver-specific overhead. However, these fields are no longer
used for for anything except logging and the 'os-hypervisors' API. Since
overhead is not reflected in placement (and therefore the scheduler),
reporting them as part of the various usage values for both logging and
that API is actually a bit of a lie and is likely to cause confusion
among users. Remove the whole thing and make our logs and the
'os-hypervisors' API better match what's stored in placement.
Change-Id: I033e8269194de54432079cbc970431e3dcea7ce5
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
In change Id62136d293da55e4bb639635ea5421a33b6c3ea2, we deprecated the
scheduler filters for CPU, RAM, and Disk since they were no longer
necessary in the new placement-based world. With these filters disabled,
we are no longer passing limits down to the resource tracker meaning we
are treating everything in the claim process as unlimited. This means
most of the claiming code here, NUMA stuff aside, is now a no-op and can
be removed. Do just that.
Change-Id: I2936ce8cb293dc80e1a426094fdae6e675461470
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
Partial-Bug: #1469179
Outside the test environment, extra_specs is usually present, even if
empty.
Although it doesn't cause test failures right now, it is fixed just
in case it might in the future.
Change-Id: I8ca6f0f37a18f81d024286a0e158353ed25fa2b5
Remove the following unit test
because it is not useful any more.
* test_pre_live_migration_instance_has_no_fixed_ip
in nova/tests/unit/compute/test_compute.py
Change-Id: I9edd70d36e7a8f40501ace574d5ae4b576a3e0ff
Closes-Bug: #1836692
The ec2 API is not in tree nor does the start instance flow
deal with injected files or availability zones so remove the
really old TODO from when the API method was added in 2011.
Change-Id: I2df5010f50c032ae57adb2d128824a05a9189f9d
These were deprecated during Stein [1] and can now be removed, lest they
cause hassle with the PCPU work. As noted in [1], the aggregate
equivalents of same are left untouched for now.
[1] https://review.opendev.org/#/c/596502/
Change-Id: I8a0d332877fbb9794700081e7954f2501b7e7c09
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Followup for [1], this creates private module-level constants for the
``need_healing`` toggle used in the code, indicating whether the
allocations need to be healed by creating them or by updating existing
allocations.
[1] https://review.opendev.org/#/c/668925/7/nova/cmd/manage.py@2069
Change-Id: I60f251cf76eeb7ec0953ad085f3606b0edf5535c
The binding:profile key might be missing from the port body but it also
can be present with a value None. So accessing the value of the
binding:profile needs special care. There is already a
_get_binding_profile() helper in neutronv2/api but still code inside
that module uses manual access in some placese. Also the heal port
allocation codepath used manual access.
So this patch makes _get_binding_profile public and replace manual
binding:profile access with the call to this helper.
Change-Id: Ic2e3ac788e74e3777e2aa4d7c36968c5e8c04a9a
The api documentation is now published on docs.openstack.org instead
of developer.openstack.org. Update all links that are changed to the
new location.
Note that Neutron publishes to api-ref/network, not networking anymore.
Note that redirects will be set up as well but let's point now to the
new location.
For details, see:
http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007828.html
Change-Id: Id2cf3aa252df6db46575b5988e4937ecfc6792bb
Compute service version 14 is from Newton [1] so we can remove
the API min compute version checks for creating a server with
bdm and vif device tags. Note that the docstrings which are
removed mentioned microversion support but that was wrong - the
request schema validation is what validates the microversion used.
[1] I8367f740d6d4ebaeb81bc74c6a82a8faf5cd8308
Change-Id: I97e67fb971b7a0cc2373b558907c7354646cf5fa
Two different error conditions in
SchedulerReportClient.delete_allocation_for_instance printed the same
warning log, which could be confusing. Reword one of them to
disambiguate.
Change-Id: Id1c5493a7270f2d0594e918df8704f671416a221
Migrations use the libvirt driver's get_host_ip_addr() method to
determine the dest_host field of the migration object.
get_host_ip_addr() checks whether CONF.my_ip is actually assigned to
one of the host's interfaces. It does so by calling
get_machine_ips(), which iterates over all of the host's interfaces.
If the host has many interfaces, this can take a long time, and
introduces needless delays in processing the migration.
get_machine_ips() is only used to print a warning, so this patch moves
the get_machine_ips() call to a single method in init_host(). This
way, a warning is still emitted at compute service startup, and
migration progress is not needlessly slowed down.
This patch also has a chicken and egg problem with the patch on top of
it, which poisons use of netifaces.interfaces() in tests. While this
patch fixes all the tests that break with that poison, it starts
breaking different tests because of the move of get_machine_ips() into
init_host(). Therefore, while not directly related to the bug, this
patch also preventatively mocks or stubs out any use of
get_machine_ips() that will get poisoned with the subsequent patch.
Closes-bug: 1837075
Change-Id: I58a4038b04d5a9c28927d914e71609e4deea3d9f
Zuul