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
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
This reverts commit aebebe713a50d1057d5dfdfa4f13be6cc3ce625b.
We said we would since the skip was temporary.
Change-Id: I5f7f5779735e158688992ccc948e7305bae1c9c4
Related-Bug: #1823251
