By default it is not possible to deattach volume that is configured
as root device for an instance.
Previous HTTP 403 reponse pointed that caller don't have permission
to deattach the volume instead he's not able to do it. Response 400
suits more for that case.
Change-Id: Ife59900448719f78c0505f1b681cb26674fa0306
Upstream Linux kernel has deleted[*] the `perf` framework integration
with Intel CMT (Cache Monitoring Technology; or "CQM" in Linux kernel
parlance), because the feature was broken by design -- an
incompatibility between Linux's `perf` infrastructure and Intel CMT
hardware support. It was removed in upstream kernel version v4.14; but
bear in mind that downstream Linux distributions with lower kernel
versions than 4.14 have backported the said change.
Nova supports monitoring of the above mentioned Intel CMT events
(namely: 'cmt', 'mbm_local', and 'mbm_total') via the configuration
attribute `[libvirt]/enabled_perf_events`. Given that the underlying
Linux kernel infrastructure for Intel CMT is removed, we should remove
support for it in Nova too. Otherwise enabling them in Nova, and
updating to a Linux kernel 4.14 (or above) will result in instances
failing to boot.
To that end, deprecate support for the three Intel CMT events in "Rocky"
release, with the intention to remove support for it in the upcoming
"Stein" release. Note that we cannot deprecate / remove
`enabled_perf_events` config attribute altogether -- since there are
other[+] `perf` events besides Intel CMT. Whether anyone is using those
other events with Nova is a good question to which we don't have an
equally good answer for, if at all.
[*] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c39a0e2
[+] https://libvirt.org/formatdomain.html#elementsPerf
Closes-Bug: #1751073
Change-Id: I7e77f87650d966d605807c7be184e670259a81c1
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
This adds a request filter that, if enabled, allows us to use placement
to select hosts in the desired availability zone by looking up the uuid
of the associated host aggregate and using that in our query for
allocation candidates. The deployer needs the same sort of mirrored
aggregate setup as the tenant filter, and documentation is added here to
make that clear.
Related to blueprint placement-req-filter
Change-Id: I7eb6de435e10793f5445724d847a8f1bf25ec6e3
Since I8ae8507a089df4d0a32be5fbc615e2166f44516e the config option
multi_instance_display_name_template has been removed.
So this patch removes the remaining of the option.
Change-Id: I81fa2588d85c803415aadf6150ed6cdd7a0fe6d1
Nova's utils.execute() is just a redirector now and should go
away, so I am progressively moving things over to calling
processutils directly.
Change-Id: I745b3433a447aeec819781e0ee26df6e6c70530a
blueprint: execs-ive-had-a-few
Change If507e23f0b7e5fa417041c3870d77786498f741d makes nova-api
dependent on placement for deleting an instance when the nova-compute
service on which that instance is running is down, also known as
"local delete".
Change I7b8622b178d5043ed1556d7bdceaf60f47e5ac80 makes nova-api
dependent on placement for deleting a nova-compute service record.
Both changes are idempotent if nova-api isn't configured to use
placement, but warnings will show up in the logs.
This change updates the upgrade docs to mention the new dependency.
Change-Id: I941a8f4b321e4c90a45f7d9fccb74489fae0d62d
Related-Bug: #1679750
Related-Bug: #1756179
While getting a HostState object for a given compute node during
scheduling, if the HostState does not have its instance info
set, either because it's out of date or because config option
"track_instance_changes" is False, the HostManager still pulls
the list of instances for that host from the database and stores
it in HostState.instances.
This is *only* used (in-tree) by the affinity filters and even
then the only thing those filters use from HostState.instances
is the set of keys from the dict, which is the list of instance
UUIDs on a given host. The actual Instance objects aren't used
at all. See blueprint put-host-manager-instance-info-on-a-diet
for more details on that.
The point of this change, is that when we go to pull the set
of instances from the database for a given host, we don't need
to join on the default columns (info_cache and security_groups)
defined in the _instance_get_all_query() method in the DB API.
This should be at least some minor optimization in scheduling
for hosts that have several instances on them in a large cloud.
As noted in the comment in the code, any out of tree filters
that rely on using the info_cache or security_groups from the
instance are now going to be hit with a lazy-load penalty
per instance, but we have no contract on out of tree filters
so if this happens, the people maintaining said filters can
(1) live with it (2) fork the HostManager code or (3) upstream
their filter so it's in-tree.
A more impactful change would be to refactor
HostManager._get_host_states to bulk query the instances on
the given set of compute nodes in a single query per cell. But
that is left for a later change.
Change-Id: Iccefbfdfa578515a004ef6ac718bac1a49d5c5fd
Partial-Bug: #1737465
This is needed for ironic use case, when during cleaning, resources
are reserved by ironic itself. Cyborg will also benefit from this
during FPGA programming.
blueprint: allow-reserved-equal-total-inventory
Change-Id: I037d9b8c1bb554c3437434cc9a57ddb630dd62f0
Change Id7eecbfe53f3a973d828122cf0149b2e10b8833f made
nova-scheduler require placement >= 1.24 so this change
updates the minimum required version checked in the
nova-status upgrade check command along with the upgrade
docs.
Change-Id: I4369f7fb1453e896864222fa407437982be8f6b5
nova.scheduler.utils.ResourceRequest now has a to_querystring method
that produces a querystring in the format expected by the GET
/allocation_candidates API. The report client now uses this method to
invoke said API.
Change-Id: I496e8d64907fdcb0e2da255725aed1fc529725f2
blueprint: granular-resource-requests
We thought we didn't have to normalize inventory (set allocation ratios
and reserved amounts from the compute node record) when taking the
update_provider_tree path in the resource tracker [1] because we wanted
the virt driver to be the source of truth for those values.
We still do want that, and that's still the case (because we only set
them if unset). But since the virt driver doesn't have access to the
compute_node object itself, until and unless we stop setting those
values on the compute_node, we still have to do that normalization even
for the update_provider_tree path. This patch makes it so.
[1] https://github.com/openstack/nova/blob/4b4e005c639204f2c680eda61131a6930379d70e/nova/compute/resource_tracker.py#L884-L886
Change-Id: I6a706ec5966cdc85f97223617662fe15d3e6dc08
The has_inventory_changed method of ProviderTree is deliberately not
automatically reporting True if the incoming record is "sparse" - that
is, for a given resource class, it only contains a subset of the keys in
the existing record. For example, the caller may want to know if the
total has changed, but doesn't care about the other fields, so may ask:
ptree.has_inventory_changed(uuid, {'VCPU': {'total': 3}, ...})
...and has_inventory_changed will only compare the 'total' field.
However, we were doing the same if the incoming record contained fields
that were *not* in the existing record. For example, if the current
inventory was:
{ 'VCPU': {
'total': 8,
'min_unit': 1,
'max_unit': 8,
'step_size': 1,
}
}
...and the new inventory was:
{ 'VCPU': {
'total': 8,
'min_unit': 1,
'max_unit': 8,
'step_size': 1,
'allocation_ratio': 16.0, # <== new
'reserved': 1, # <== new
}
}
...the presence of the new fields was *not* enough to trigger a True
response.
This is problematic because we currently expect to be able to add
specifically these fields - allocation_ratio and reserved - to an
inventory record if they are not present (see [1]).
With this change set, we add a condition to automatically return True
(inventory *has* changed) whenever the incoming (new) record contains
fields absent from the existing record.
[1] https://github.com/openstack/nova/blob/050e9202f69b6eeb23026b7350eeb8821ca9f1cc/nova/compute/resource_tracker.py#L83-L125
Partial-Bug: #1771728
Change-Id: I80dd6d08322bcedc8535f04baf2e96473f5e3aeb
We've had a long-standing optimization point in the
InstanceList.get_uuids_by_host() method, where we pull the entire
list of instance objects only to strip and return the uuids. We
already had a query method for generating just the uuids in the
DB API, but it was not exposed as it was just a helper for another
method. This exposes it publicly and uses it in that InstanceList
method.
Change-Id: I35c05e78d59ec9b95c2a443979b8d66cd42ea043
The instance.refresh() method is careful to prevent recursion, to avoid
lazy-loads on the object we just pulled from the database. However, it
was allowing those to raise OrphanedObjectError to the caller to make
them visible. The caller is not really at fault in that case, and can not
avoid it.
The only time this has ever come up is in the context of cellsv1 and the
keypairs field that it doesn't have set on instances in the child cells.
Thus, this changes refresh() to just skip fields that are set on the
current object and unset on the one we pull from the database, as we
would not be able to refresh those anyway. This logs the situation so that
it is visible (at DEBUG) if it becomes relevant.
Change-Id: Ibfca4ae922766b5b977e217594d12e1169ddeee8
Previously we had a trivial block on the lazy-load handler for instance
that prevented loading mundane things that couldn't be opted-out during
a query. There's no real reason for that and we already had the generic
loader mechanism.
This removes that limit, and adjusts some of the logic in obj_load_attr()
to continue providing the same behavior for things like id and uuid being
missing (which we have lots of existing coverage for). The new behavior
of being able to load something like vm_state gets a new test, which also
validates that _load_generic() loads anything else it can from the instance
it fetches from the database, if not already set on the object initiating
the load.
Change-Id: Id0f4027f1fffefdb90240fc484cf3c0554e576d9
Since max_attempts is not max_retries, we should look for max_attempts-1
alternate hosts. This change makes the num_alts variable actually reflect
the number of alternates we are looking for, and doesn't actually change
the logic at all. This also adds functional tests to verify max_attempts
behavior with 1 (no retries) and 2 (one retry), just to make sure it is
doing what we expect.
Further, we optimize _get_alternate_hosts() to only re-filter/weigh the
host list if we're looking for alternates for multiple instances. Now
that it's clear that num_alts is only nonzero if we are going to look
at the host list again to find those alternates, it can be more clearly
(and accurately) used to optimize out that extra step if we are not
getting alternates.
Change-Id: I16ba29385dd2db5467829e6c17fc395096b5cfd3
Option "os_region_name" from group "placement" is deprecated. Use
option "region_name" from group "placement".
Change-Id: Id44d456bb1bdb0c5564ad4f5d9cdee2f41226052
Related-Bug: #1762106
Replace mox with mock in the following methods
of the LibvirtConnTestCase
in nova/tests/unit/virt/libvirt/test_driver.py.
* _mock_can_live_migrate_source
* test_check_can_live_migrate_source_block_migration
* test_check_can_live_migrate_source_shared_block_storage
* test_check_can_live_migrate_source_shared_instance_path
* test_check_can_live_migrate_source_non_shared_fails
* test_check_can_live_migrate_source_shared_block_migration_fails
* test_check_can_live_migrate_shared_path_block_migration_fails
* test_check_can_live_migrate_non_shared_non_block_migration_fails
* test_check_can_live_migrate_source_with_dest_not_enough_disk
* _do_test_create_images_and_backing
Subsequent patches will replace mox in other test cases.
Change-Id: Ia9167f7843bec2210176c472e4946e8ba3a1c72a
Implements: blueprint mox-removal
According to libvirt doc[1], migrateToURI3 supports
args(dconnuri, params, flags) but not logical_sum.
We call migrateToURI3 with arg flags in guest.py [2].
The wrong fake func may cause error in functional tests of nova.
With logs below:
"/home/zuul/src/git.openstack.org/openstack/nova/nova/virt/libvirt/guest.py",
line 669, in migrate'
' destination, params=params, flags=flags)'
"TypeError: migrateToURI3() got an unexpected keyword argument 'flags'"
[1] https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrateToURI3
[2] https://github.com/openstack/nova/blob/050e92/nova/virt/libvirt/guest.py#L668
Change-Id: I88d71bac7ddb69b9b63fb58dd8eaf6c048017933
Zuul