Resetting was in place but it was done after the retry filter is
populated in the MigrationTask by the populate_retry call. This
patch moves the reset code before the call to populate_retry as
to allow retries.
Change-Id: I8290e890a36cf5a8f409ab8a50e7c72f7ae15025
Closed-Bug: #1845291
Nova does not try to re-schedule a migration if the original boot was
done with --availability-zone <az:host> or <az::node>.
Related-Bug #1845291
Change-Id: Id78627c5c08090de6220249a5f44d26bf32724af
This has been fixed but not released. Another warning is updated since
modules don't have .py extensions.
Change-Id: Iaa93b9743214300597650040c1cd34699f12ab3f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Related-Bug: #1813147
The 'message' argument is a regex so you need to escape brackets and the
likes. Strange that this worked on py27.
This was coincidentally fixed by Ib9f735216773224f91ac7f49fbe2eee119670872
in Train but this change is backportable while that one is not.
Change-Id: Ia1f0fa6a46bdd0a87d40721937355b2cc887f1c9
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Related-Bug: #1813147
We don't need to do a whole lot here. The key things to note are that
some host level configuration is now necessary, that the 'isolate' CPU
thread policy behaves slightly differently, and that you can request
'PCPU' inventory explicitly instead of using 'hw:cpu_policy=dedicated'
or the image metadata equivalent.
Part of blueprint cpu-resources
Change-Id: Ic1f98ea8a7f6bdc86f2d6b4734774fa380f8cc10
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The documentation for emulator threads leaves a lot to be desired, while
the hierarchy of the CPU thread pinning doesn't emphasise the dependency
of this feature on CPU pinning. Resolve both by tweaking or expanding
the wording of key paragraphs and modifying the header levels to nest
the CPU thread pinning and emulator thread pinning docs under the CPU
pinning docs.
Change-Id: Ife32a53b80b770e008dbe2091fbb88e6596d238b
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
In the depends-on the upgrade notes in placement are moved to a
different URL. Because the link here in nova was to an anchor, not
a URL, a redirect on the placement side will not catch this, so
explicitly update the link.
Depends-On: https://review.opendev.org/683783
Change-Id: Ib07eacb9150bbb8b0726cfe06ae334c7a764955c
Multiple functional tests used its own copy-pasted implementation of a
weigher to make the scheduling deterministic based on host names.
This patch moves the HostNameWeigher implementation to a common place
and adds a fixtures to set up the weigher in the conf.
Change-Id: I4c23a3c4f8963c42379e7a8d63c6c1e089350eb3
The compat code for the request spec in _cold_migrate is
nearly as big as the rest of the method. This moves that to
another method and also slides the image meta handling within
the first condition where it's needed and renames the 'image'
variable to 'image_meta' to stop shadowing the 'image' module
import.
Change-Id: I83e1a1eba594897f4610e1f9074a24d79443a025
Prior to change I4244f7dd8fe74565180f73684678027067b4506e in Stein,
conductor would pass a legacy dict request spec to compute during
cold migrate / resize and if compute rescheduled it would not pass
the request spec back to conductor, so the _cold_migrate method in
conductor would have to create a new RequestSpec from components
it had available.
As of that change, compute will send the request spec it got back
to conductor and _cold_migrate avoids the RequestSpec.from_components
call.
There are two issues here:
1. Technically if conductor RPC API is pinned to less than 1.13 the
ComputeTaskAPI.migrate_server method will remove the request spec
from the call to conductor. So conductor (server-side) can still
not get a RequestSpec and need to use from_components. As a result
the TODO in the _cold_migrate method needs to be updated since we
require an RPC API major version bump to make request spec required.
2. Just because conductor is passing compute a RequestSpec object, if
compute RPC API versions are pinned to less than 5.1, conductor will
pass a legacy request spec dict to compute and compute will send that
back to conductor, so the _cold_migrate method needs to handle getting
a request spec that is a dict and convert it to an object. A new test
is added for that case.
Change-Id: I188b7aa9cb220f93e69a68f0c3592b28d41ba5b6
Closes-Bug: #1843090
This adds some simple functional tests for the API validation
behavior during server create when [cinder]/cross_az_attach=False
meaning the server being created and any volumes attached to it
must be in the same AZ.
As part of this, bug 1694844 is recreated where the server is
created without an AZ (or default_schedule_zone AZ) which results
in a 400 response because None != whatever the volume's AZ is
(which defaults to "nova" in Cinder). This is important for testing
fixes for that bug later since the API interaction code is pretty
hairy and unit tests are insufficient for validating a fix.
Change-Id: I1b724f7ad3e2f6baa9fd865a8e22d87bf909b488
Related-Bug: #1694844
In change I3fd9fe0317bcd1a59c366e60154b095e8df92327, we deprecated the
'--version' option in favour of a 'VERSION' positional. This was later
removed in change I7795e308497de66329f288b43ecfbf978d67ad75. Update the
docs to reflect this. 'nova-manage api_db sync' were already corrected
in change Ibc49f93b8bd51d9a050acde5ef3dc8aad91321ca and does not need
the same fix, though a minor tweak is included.
Change-Id: I2c0fb04fbc3f6d2074596894782ed3143b0c2338
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Closes-Bug: #1840807
I forget this every darn time I'm working on something that requires DB
migrations.
Change-Id: I6ca988793cf2bfc2d5938acc158fd94e61e06a92
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
One of the PortUpdateFailed exception usage case introduced by the
bp support-move-ops-with-qos-ports overly chatty about upgrade and
pinned RPC. This message can reach the end user during resize so the
deployment specific information is removed from the exception message
and logged instead. Also a TODO is added that the whole check can be
removed once we bump the compute RPC to 6.0
Change-Id: I37b02da02a42cab09d2efe6d1a4b88cbc8b9b0d0
The MigrationTask in the conductor already checks the service version as
old computes cannot support migration with QoS port. However it is still
possible that every compute is new but the compute RPC API is pinned to
< 5.2. In this case the migration still cannot be supported.
This patch adds an extra RPC version check to the conductor.
Change-Id: Ib4e0b9ab050a59ab5a290e6eecea01b87c3bd4c6
Closes-Bug: #1844993
If we get an unexpected exception during boot from volume while
validating a pre-created volume, we just raise InvalidBDMVolume
which might have a misleading error message for why validation
failed, e.g. it looks like we couldn't GET the volume but actually
it could be something in later validation that fails.
This simply logs the error at INFO level for later debugging. We
don't log at WARNING or ERROR because it could be due to some user
error and operators shouldn't have to worry about warnings/errors
in the logs for user-inflicted issues. The INFO log is useful though
in diagnosing a failure if the user doesn't understand the failure.
Change-Id: I83903593811efe43608826c8e599c8f09c313a3c
If the compute RPC is pinned to < 5.2 a server with QoS port cannot be
migrated. However nova not just fails the migration but also leaves the
server and the QoS port in an inconsistent state.
Change-Id: Ia8dc51d11b8ce93c372ee77f2c0b43910f992574
Related-Bug: #1844993
Zuul