Notes: fakes.py/stub_out_key_pair_funcs() is already fixed
in another changeset.
Partially-Implements: blueprint mox-removal
Change-Id: I53333eb6f46bf4234de669f52558a256b627af44
The ability to list instance actions for deleted servers was
added in the 2.21 microversion, so we should update the wording
to make that clear.
Change-Id: Ibf05d5bd2c70aa579bb2a688d4d5fa63278176d2
noVNC 1.0.0 has the fix for non-US key mappings so this adds a simple
note when installing the novnc package that at least 1.0.0 should be
used for non-US key map support.
Change-Id: Ia1a84c986025f8a46c1062440faa0deb1d2d73a5
Related-Bug: #1682020
Introduce placement microversion 1.18 with a new ?required=<trait list>
query parameter accepted on the GET /resource_providers API. Results
are filtered by providers possessing *all* of the specified traits.
Empty/invalid traits result in 400 errors.
Change-Id: I8191c9a390cb02b2a38a3f1c6e29457435994981
blueprint: traits-on-list-resource-providers
It was pointed out [1] that the semantic difference between how the
`resources` query parameter is handled by GET /resource_providers versus
GET /allocation_candidates is not clear based on the API reference
descriptions, which are identical. This change set clarifies the
wording for both, making it clear that a) allocations are taking into
account; and b) GET /allocation_candidates is working with groups of
providers that must *collectively* satisfy the resource specification.
[1] https://review.openstack.org/#/c/547056/2/specs/rocky/approved/traits-on-list-resource-providers.rst@33
Change-Id: Ia2a4f8f80ec68dd9c95e084c292a2fe2d6ec1b2d
If an instance is deleted before it is scheduled, the BDM
clean-up code uses the mappings from the build request as
they don't exist in the database yet.
When using the older attachment flow with reserve_volume,
there is no attachment_id bound to the block device mapping
and because it is not loaded from database but rather from
the build request, accessing the attachment_id field raises
an exception with 'attachment_id not lazy-loadable'
If we did a new style attach, _validate_bdm will add the
attachment_id from Cinder. If we did not, then this patch
will make sure to set it to 'None' to avoid raising an
exception when checking if we have an attachment_id set in
the BDM clean-up code
Change-Id: I3cc775fc7dafe691b97a15e50ae2e93c92f355be
Closes-Bug: #1750666
When we run detach_volume(), the guest has to respond to the ACPI
eject request in order for us to proceed. It may not do this at all
if the volume is mounted or in-use, or may not by the time we time out
if lots of dirty data needs flushing. Right now, we let the failure
exception bubble up to our caller and we log a nasty stack trace, which
doesn't really convey the reason (and that it's an expected and
reasonable thing to happen).
Thus, this patch catches that, logs the situation at warning level and
avoids the trace.
Change-Id: I3800b466a50b1e5f5d1e8c8a963d9a6258af67ee
Closes-Bug: #1750680
When creating a new instance and deleting it before it gets scheduled
with the old attachment flow (reserve_volume), the block device mappings
are not persisted to database which means that the clean up fails
because it tries to lookup attachment_id which cannot be lazy loaded.
This patch adds a (failing) functional test to check for this issue
which will be addressed in a follow-up patch.
Related-Bug: #1750666
Change-Id: I294c54e5a22dd6e5b226a4b00e7cd116813f0704
If the user creates a volume-backed server from an existing
volume, the API reserves the volume by creating an attachment
against it. This puts the volume into 'attaching' status.
If the user then deletes the server before it's created in a
cell, by deleting the build request, the attached volume is
orphaned and requires admin intervention in the block storage
service.
This change simply pulls the BDMs off the BuildRequest when
we delete the server via the build request and does the same
local cleanup of those volumes as we would in a "normal" local
delete scenario that the instance was created in a cell but
doesn't have a host.
We don't have to worry about ports in this scenario since
ports are created on the compute, in a cell, and if we're
deleting a build request then we never got far enough to
create ports.
Change-Id: I1a576bdb16befabe06a9728d7adf008fc0667077
Partial-Bug: #1404867
This is another wrinkle for bug 1404867 where we create a
volume-backed server, create an attachment on the volume which
puts the volume in 'attaching' status, and then delete the server
before it's actually created in a cell.
In this case, the _delete_while_booting code in the compute API
finds and deletes the BuildRequest before the instance was ever
created in a cell.
The bug is that _delete_while_booting in the API doesn't also
process block device mappings and unreserve/delete attachments
on the volume, which orphans the volume and can only be fixed
with admin intervention in the block storage service.
Change-Id: Ib65acc671711eae7aee65df9cd5c6b2ccb559f5c
Related-Bug: #1404867
Usually, when instance.host = None, it means the instance was never
scheduled. However, the exception handling routine in compute manager
[1] will set instance.host = None and set instance.vm_state = ERROR
if the instance fails to build on the compute host. If that happens, we
end up with an instance with host = None and vm_state = ERROR which may
have ports and volumes still allocated.
This adds some logic around deleting the instance when it may have
ports or volumes allocated.
1. If the instance is not in ERROR or SHELVED_OFFLOADED state, we
expect instance.host to be set to a compute host. So, if we find
instance.host = None in states other than ERROR or
SHELVED_OFFLOADED, we consider the instance to have failed
scheduling and not require ports or volumes to be freed, and we
simply destroy the instance database record and return. This is
the "delete while booting" scenario.
2. If the instance is in ERROR because of a failed build or is
SHELVED_OFFLOADED, we expect instance.host to be None even though
there could be ports or volumes allocated. In this case, run the
_local_delete routine to clean up ports and volumes and delete the
instance database record.
Co-Authored-By: Ankit Agrawal <ankit11.agrawal@nttdata.com>
Co-Authored-By: Samuel Matzek <smatzek@us.ibm.com>
Co-Authored-By: melanie witt <melwittt@gmail.com>
Closes-Bug: 1404867
Closes-Bug: 1408527
[1] https://github.com/openstack/nova/blob/55ea961/nova/compute/manager.py#L1927-L1929
Change-Id: I4dc6c8bd3bb6c135f8a698af41f5d0e026c39117
Under certain failure scenarios it may be that although the libvirt
definition for the volume has been removed for the instance that the
associated storage lun on the compute server may not have been fully
cleaned up yet.
In case users try an other attempt to detach volume we should not stop
the process whether the device is not found in domain definition but
try to disconnect the logical device from host.
This commit makes the process to attempt a disconnect volume even if
the device is not attached to the guest.
Closes-Bug: #1727260
Change-Id: I4182642aab3fd2ffb1c97d2de9bdca58982289d8
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@redhat.com>
Resource allocation test case:
Initiate evacuation when no valid host to evacuate to and
check all resource usages and allocations after.
This testcase uncovered the bug below. Bug is fixed already, so the
test contains asserts that cover the correct behavior.
Related-Bug: #1713783
Change-Id: I4ced19bd9259f0b5a50b89dd5908abe35ca73894
Currently the nova-manage delete_cell command with the --force option
allows us to destroy hosts_mappings of the cell which does not have any
instances or instance_mappings. This patch extends this command with the
--force option for destroying instance_mappings in addition to the
host_mappings of the cell which is to be deleted. Note that the instance
mappings and host mappings are only removed if there are no living
instances in the cell. So a --force delete here will not work if there
are non-deleted instances.
Change-Id: Ibefa0465224bec9a22431c7d3b5c8f5d91fc7732
Closes-Bug: #1745375
Dao Cong Tien