nova compute will call check_can_live_migrate_destination when doing
live migration and it will compare cpu model, however, following info
indicated that cpu compare is not supported at s390x arch.
URI qemu:///system does not support full set of host capabilities: this
function is not supported by the connection driver:
cannot compute baseline CPU of s390x architecture
https://www.libvirt.org/news.html has the info
v5.9.0 has Improvements part indicated the compare was added at 5.9
so the workaround is to avoid the check and let the migration proceed.
Change-Id: I253f4f305ecf8b5331212be87caef41f2ebb747e
Closes-Bug: 1854126
This is to to fix an invalid assertIsNotNone statement,
"self.assertIsNotNone('migration_context', self.task.instance)",
which will never raise an exception.
Change-Id: I7264238a50f5320500696312cff63dcc0e728810
This passes graceful_exit=True to the wrap_instance_event decorator
in ComputeTaskManager.revert_snapshot_based_resize so that upon successful
completion of the RevertResizeTask, when the instance is hard destroyed
from the target cell DB (used to create the action/event), a traceback
is not logged for the InstanceActionNotFound exception.
The same event is also finished in the source cell DB upon successful
completion of the RevertResizeTask. Note that there are other ways we
could have done this, e.g. moving the contents of the _execute() method
to another method and then putting that in an EventReporter context with
the source cell context/instance, but this was simpler.
Part of blueprint cross-cell-resize
Change-Id: Ibb32f7c19f5f2ec4811b165b8df748d1b7b0f9e4
This adds a kwarg to wrap_instance_event to be used in the
EventReporter to allow the caller to tell EventReporter to
gracefully handle InstanceActionNotFound on __exit__.
This will be used by ComputeTaskManager.revert_snapshot_based_resize
which starts an action in the target cell DB but upon successful
exit of the RevertResizeTask the instance in the target cell DB
will be hard destroyed resulting in an InstanceActionNotFound
traceback which should be avoided.
Part of blueprint cross-cell-resize
Change-Id: Ie48a9c0a285f77e260f675fbe9282df9f02282b1
This adds two tests and updates the cross-cell resize docs to
show that _poll_unconfirmed_resizes can work if the cells are
able to "up-call" to the API DB to confirm the resize. Since
lots of deployments still enable up-calls we don't explicitly
block _poll_unconfirmed_resizes from processing cross-cell
migrations. The other test shows that _poll_unconfirmed_resizes
fails if up-calls are disabled.
Part of blueprint cross-cell-resize
Change-Id: I39e8159f3e734a1219e1a44434d6360572620424
This implements the cleanup_instance_network_on_host method
in the neutron API which will delete port bindings for the
given instance and the given host, similar to how
setup_networks_on_host works when teardown=True and the
instance.host does not match the host provided to that method.
This allows removing the hacks in the
_confirm_snapshot_based_resize_delete_port_bindings and
_revert_snapshot_based_resize_at_dest methods.
Change-Id: Iff8194c868580facb1cc81b5567d66d4093c5274
Rather than copy the instance action event from the target
cell DB to the source cell DB when
_finish_snapshot_based_resize_at_dest fails on the dest host,
we can simply use the EventReporter context in conductor with
the source cell context and get the same event.
Part of blueprint cross-cell-resize
Change-Id: I8053765797f097859bf585459f4a00d31844708e
This tries to strike a balance between giving a useful high level
flow without injecting too much complex detail in each diagram.
For the more complicated resize diagram, I have used labels to
try and make clear which conductor task is performing an action.
For the less complicated confirm and revert diagrams, I add a
separator to show where the conductor task is orchestrating the
calls and provide a bit more detail into what each task is doing
since the calls to computes are minimal in those cases.
Part of blueprint cross-cell-resize
Change-Id: I27c549901a3359f106ba5d77aa6559397ee12a5d
This gives most of the high level information. I'm sure there
are more troubleshooting things we can add but those could come
later as they crop up.
The sequence diagram(s) will come in a separate change.
Part of blueprint cross-cell-resize
Change-Id: I13f07a2d45bf5b8584adc8aa079bae640cb5c470
This changes the nova-multi-cell job to essentially
force cross-cell resize and cold migration. By "force"
I mean there is only one compute in each cell and
resize to the same host is disabled, so the scheduler
has no option but to move the server to the other cell.
This adds a new role to write the nova policy.yaml file
to enable cross-cell resize and a pre-run playbook so
that the policy file setup before tempest runs.
Part of blueprint cross-cell-resize
Change-Id: Ia4f3671c40e69674afc7a96b5d9b198dabaa4224
This adds the "compute:servers:resize:cross_cell" policy
rule which is now used in the API to determine if a resize
or cold migrate operation can be performed across cells.
The check in the API is based on:
- The policy check passing for the request.
- The minimum nova-compute service version being high
enough across all cells to perform a cross-cell resize.
If either of those conditions fail a traditional same-cell
resize will be performed.
A docs stub is added here and will be fleshed out in an
upcoming patch.
Implements blueprint cross-cell-resize
Change-Id: Ie8a0f79a3b16e02b7a34a1b81f547013a3d88996
jichenjc