There was no code in FakeDriver that updated the internal
dict `self.instances` when a FakeInstance was live migrated.
This commit fills this gap. As a result, a couple of versioned
notification samples get updated since we are now properly
tracking a live migrated instance on the destination host as
running vs pending power state.
Closes-Bug: 1426433
Change-Id: I9562e1bcbb18c7d543d5a6b36011fa28c13dfa79
This test creates 2 servers which take up all of the
CUSTOM_PMEM_NAMESPACE_SMALL resources on the sole host in
the test. Then it tries to create a 3rd server which it
expects to fail and it does. Then it deletes the second
server to free up one CUSTOM_PMEM_NAMESPACE_SMALL resource
on the host and schedules another server which it expects
to work. The problem is the test doesn't wait for the
second server to be fully deleted so the test intermittently
fails when the CUSTOM_PMEM_NAMESPACE_SMALL resource isn't
yet freed up when the fourth server goes through scheduling.
This adds a simple wait call for the deleted server to actually
be gone before creating the fourth server.
Change-Id: Id3389038b5fed1e70dd12c7ed9cef2c0950625cf
Closes-Bug: #1856902
ImageMetaPropsPayload (for notifications) was supposed to contain
exactly the same fields as ImageMetaProps itself; and the SCHEMA member
was those same keys in a trivially different shape. And we were having
trouble remembering to keep these two objects in sync before. So this
commit eliminates the repetition and just generates
ImageMetaPropsPayload's `fields` and `SCHEMA` from
ImageMetaProps.fields.
Change-Id: I7dc38f7f5a62098fb0c366736f27e23bd7b7ee86
This change adds missing fields to the image metadata
notification object and adds a unit tests to assert
that the notification object and nova object stay in sync.
This change also adds unit tests to assert the notification
schema and fields are in sync and that the schema is
valid.
Change-Id: I36ea5d5e677ab3e6c88223b20f5377e9471c55db
Closes-Bug: #1856100
This patch moves _update_pci_request_spec_with_allocated_interface_name
from the ComputeManager to nova.compute.utils as a later patch needs to
call it from outside of the ComputeManager.
This patch also changes the exception types raised from
update_pci_request_spec_with_allocated_interface_name as raising
BuildAbortException from a util method does not make too much
sense. This means that some of the callers also needed to be adjusted to
handle the new exception types.
In the _do_rebuild_instance_with_claim code path the exception type is
not translated back to BuildAbortException as the old and the new
exceptions are both handled by the except Exception branch in
rebuild_instance [1].
[1] https://github.com/openstack/nova/blob/ed503ce3e1a8598c6e8ee9d8b345c1d92df01539/nova/compute/manager.py#L3448
Change-Id: I5853a0f6e133044ffc1861d21008e568ad62ffc7
blueprint: support-move-ops-with-qos-ports-ussuri
This reverts commit 33a2a5f2e4. We're now
at M1 and the DevStack default has been changed. We no longer need to
pretend to support Python 2.7. This is slightly modified to drop an
additional Python 2.7-only dependency from lower-constraints.txt.
[1] I52b03caee0ba700da3a15035201ea6cd91baa06b
Change-Id: I1068850072e639ee268d68ca82249f569a40310e
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
FinishResizeAtDestTask needs to refresh its local copy of the target
cell instance after finish_snapshot_based_resize_at_dest to make sure
it has the latest copy of the instance before updating it in
_update_instance_mapping otherwise if the instance is dirty conductor
could overwrite fields set by the compute, like the flavor.
Part of blueprint cross-cell-resize
Change-Id: If6e1acb0efe1d7bac460deff2d9572ef7170f79d
This implements one of the test todos where we create a server
and attach a volume to it, resize to another cell, detach the
volume while the instance is in VERIFY_RESIZE status, and then
revert the resize and make sure the volume is still detached
from the source cell after the revert.
A log message is added to prep_snapshot_based_resize_at_source
which was useful while debugging the new test.
Part of blueprint cross-cell-resize
Change-Id: I89aef20eebb817822d830db178527c370e532f54
This adds the logic to the API revertResize
operation such that if the migration is a cross-cell
resize the API will RPC cast to conductor to
revert the resize rather than directly to the dest
compute service like a traditional resize. Conductor
will then orchestrate the revert process between the
source and target cell.
Now that the API has revertResize plumbed this change
builds on the cross-cell resize functional tests by
reverting the resize for the volume-backed server test
and adds a revert from stopped image-backed test.
Part of blueprint cross-cell-resize
Change-Id: Iad211a54719c5fde039c48072c58f3af96afc8b8
This adds the conductor ComputeTaskManager method
revert_snapshot_based_resize along with the related conductor
RPC API client method which will be an RPC cast from the API
for a revertResize server action.
Part of blueprint cross-cell-resize
Change-Id: Ia6b6b25238963a5f60349267da6d07cb740982f4
This implements the TODO in the RevertResizeTask.rollback
method by logging an exception with some details and also
setting the instance to ERROR state, recording a fault
and sending an error notification, similar to the rollback
method in ConfirmResizeTask.
As noted inline, the exception message could be more detailed
but I've left that for a later change in case people want more
details.
Part of blueprint cross-cell-resize
Change-Id: I41296696da3226767d2bacba9345d829529ce4b6
This adds the RevertResizeTask which will be used to orchestrate
the revert of a cross-cell resize. It is responsible for updating
the instance mapping and hidden fields to hide the target cell
instance and show the source cell instance, clean up the target
host / cell, destroy the target cell instance, and (re)spawn the
instance in the source cell.
Part of blueprint cross-cell-resize
Change-Id: I7069f8807f353fa63c96494395bbbf7cc44562fb
This adds the finish_revert_snapshot_based_resize_at_source() method
to the compute service. This completes the cross-cell resize revert
on the source host by updating port bindings, re-connecting volumes
and spawning the guest and waiting for the network-vif-plugged
event from neutron.
If the resize started with a stopped instance, the revert ensures
the guest is powered off when it is spawned.
The instance record is updated with the old_flavor information,
allocations are reverted in placement, and the migration status in
the source cell database is updated to "reverted".
Notifications are not sent from this method like in the
finish_revert_resize() method because those will be sent from
conductor.
Note that this implementation tries to be a bit more graceful
about error handling than the old same-cell finish_revert_resize
method since there are a lot of moving parts and we want to try
to clean up as much as possible.
Part of blueprint cross-cell-resize
Change-Id: I7e7afddbd9e0f57dfb1175a0bb2b54f2ed5500f2
When reverting a cross-cell resize, conductor will:
1. clean up the destination host
2. set instance.hidden=True and destroy the instance in the
target cell database
3. finish the revert on the source host which will revert the
allocations on the source host held by the migration record
so the instance will hold those again and drop the allocations
against the dest host which were held by the instance.
If the ResourceTracker.update_available_resource periodic task runs
between steps 2 and 3 it could see that the instance is deleted
from the target cell but there are still allocations held by it and
delete them. Step 3 is what handles deleting those allocations for
the destination node, so we want to leave it that way and take the
ResourceTracker out of the flow.
This change simply checks the instance.hidden value on the deleted
instance and if hidden=True, assumes the allocations will be cleaned
up elsehwere (finish_revert_snapshot_based_resize_at_source).
Ultimately this is probably not something we *have* to have since
finish_revert_snapshot_based_resize_at_source is going to drop the
destination node allocations anyway, but it is good to keep clear
which actor is doing what in this process.
Part of blueprint cross-cell-resize
Change-Id: Idb82b056c39fd167864cadd205d624cb87cbe9cb
This adds the revert_snapshot_based_resize_at_dest() compute
service method which will be called from conductor during
a cross-cell resize revert operation. This runs on the dest
host in the target cell and is similar to
confirm_snapshot_based_resize_at_source() except it destroys
the guest and works on dropping the new_flavor resource usage
rather than the old_flavor. It also sends the legacy
"compute.instance.exists" notification like a traditional
revert_resize().
As part of this cleanup, the dest host volume attachments
are deleted. The source host port bindings, which are inactive
when this runs, are activated and then the (previously active)
dest host port bindings are deleted. This is to make sure the
ports are not left unbound after the revert.
Part of blueprint cross-cell-resize
Change-Id: I200c51acbbda767c2d8ff90103eef54dbf35fb01
This adds the logic to the API confirmResize
operation such that if the migration is a cross-cell
resize the API will RPC cast to conductor to
confirm the resize rather than directly to the source
compute service like a traditional resize. Conductor
will then orchestrate the confirm process between the
source and target cell.
Now that the API has confirmResize plumbed this change
builds on the cross-cell resize functional tests by
confirming the resize for the image-backed server test.
To make that extra fun, a volume is attached to the
server while it is in VERIFY_RESIZE status to assert it
remains attached to the instance in the target cell
after the resize is confirmed.
In addition, the FakeDriver.cleanup() method is updated
to guard against calling it before the guest is destroyed
from the "hypervisor". This is to make sure the cleanup()
method is called properly from
confirm_snapshot_based_resize_at_source() in the compute
service on the source host.
The _confirm_resize_on_deleting scenario will be
dealt with in a later change.
Part of blueprint cross-cell-resize
Change-Id: Ia5892e1d2cb7c7685e104466f83df7bb00b168c0
This adds the conductor ComputeTaskManager method
confirm_snapshot_based_resize along with the related conductor
RPC API client method which by default will be an RPC cast
from the API for a confirmResize server action but can also
be RPC called in the case of deleting a server in VERIFY_RESIZE
status.
Part of blueprint cross-cell-resize
Change-Id: If4c4b23891bfc340deb18a2f500510a472a869c9
Lorenzo Affetti