The combined fixes for the two related bugs resolve the problem where
SIGHUP breaks the nova-compute service. Bump the minimum requirements
for oslo.privsep and oslo.service to make sure these fixes are in place,
and add a reno to advertise resolution of the issue.
This also bumps oslo.utils to match the lower constraint from
oslo.service.
Change-Id: I39ead744b21a4423352a88573f327273e4d09630
Related-Bug: #1794708
Related-Bug: #1715374
The '_update_provider_tree_for_vgpu' argument took an 'inventories_dict'
argument, but that argument was generated immediately before the sole
call to the function. Just generate the argument inside the function
itself.
Change-Id: Id026855c06e047023b8092a45a0c3e02364c3dbb
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Otherwise we overload the import with the 'fields' variable defined on
the class.
Change-Id: Ife4646eb8da78cc25baddddfd3eb8c7d360352b3
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
We're using placement. Let's make sure everything is working in concert
and requesting the right amount and types of things.
Change-Id: Ieea576b700327ba5a5300e512d42e51a255abbba
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Co-authored-by: Bhagyashri Shewale <bhagyashri.shewale@nttdata.com>
Nothing was overriding a number of these fields so make things less
complex by removing the customizability. We can easily re-add it if we
need to in the future. We can do more here (most callers of this use the
exact same values), but that's a change for later.
Change-Id: Id3e0668acb71b3c7350b73b4afff7e940c6dfb1d
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
We would like nova not to use ironicclient, but instead to invoke the
ironic API directly through an openstacksdk connection.
The parent commits set up the framework, and this commit uses it
for the _set_instance_id function.
Blueprint: openstacksdk-in-nova
Change-Id: I95f3414d29a5ff5cc49994bac1cda917edc4f292
We would like nova not to use ironicclient, but instead to invoke the
ironic API directly through an openstacksdk connection.
The parent commits set up the framework, and this commit uses it
for the instance_exists function.
Blueprint: openstacksdk-in-nova
Change-Id: I764b0086d0bf39d4ca8cb308696169282b12b42b
The '_test_simple_call' test is unused since change
Ibcb6bf912b3fb69c8631665fef2832906ba338aa.
Change-Id: If9e36cb4a21ced44f2ee7dede480a0719fcccdf1
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Matt pointed out in [1] that there is missing test coverage for some of
the changes in If1f465112b8e9b0304b8b5b864b985f72168d839 for the rpc api
behavior. So this follow up adds the extra unit tests.
[1] https://review.opendev.org/#/c/655721/17/nova/compute/rpcapi.py@615
Change-Id: I5e837f30c888ed2fa63856670695d2836cf48e00
blueprint: support-move-ops-with-qos-ports
In a future change, I492803eaacc34c69af073689f9159449557919db, we're
going to be adding a new field to all definitions of this object. That
is going to result in a lot of line wrapping which will make the change
a lot harder to grok. Do that wrapping now so that we can make the
functional changes in that future change easier to identify.
Part of blueprint cpu-resources
Change-Id: Id3441073adde563a568c9550df53690d1e6c998a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
<launchSecurity> enables use of SEV, so add the required config class
for it. For now the class just describes the new element; it will be
used in further commits.
Furthermore, AMD SEV requires enabling DMA APIs for virtio devices
via <driver iommu='on' />:
http://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html#proposed-change
So also add the necessary bits for that to domain configuration.
blueprint: amd-sev-libvirt-support
Change-Id: Ia78458ac698f66d297cb91bcab663fcf123c5442
Add a new "hw:mem_encryption" extra spec parameter, and a new
"hw_mem_encryption" image property, which indicate that any guest
booted with that extra spec parameter or image property respectively
needs to be booted with its memory hardware-encrypted.
This is achieved by converting the requirement stated in the extra
spec parameter and/or image property into an additional extra spec
parameter which requests resources for one slot of the inventory of
the new MEM_ENCRYPTION_CONTEXT resource class (introduced in
os-resource-classes 0.4.0). The inventory will be provided by the
follow-up commit I659cb77f12a38a4d2fb118530ebb9de88d2ed30d.
Since future commits adding support for SEV to guest XML config will
also need to know at launch-time whether memory encryption has been
requested, add a reusable mem_encryption_requested() function to the
nova.virt.hardware library for detecting which of the extra spec /
image property (if either) have requested encrypted memory.
If both the extra spec parameter and the image property are explicitly
specified and they contradict each other, or if either request memory
encryption but the image does not have hw_firmware_type set to UEFI,
then log an error and raise a new generic FlavorImageConflict
exception. This exception can also be useful in the future for
handling other similar conflicts. In this particular use case,
FlavorImageConflict is raised by mem_encryption_requested(), and then
if caught during API call validation, it's re-raised as
HTTPBadRequest.
In order to test this code, we need to construct various ImageMeta
objects containing fake data and a ImageMetaProps instance for each.
This is a slightly fiddly task which future patches in the SEV series
will also need to perform, so add a helper to nova.tests.unit.image.fake
for this.
blueprint: amd-sev-libvirt-support
Change-Id: I8c63b5cc5ad97ce831adb2eb96a995ebc798ecb7
Nova intentionally does not persist the resoruce request of the neturon
ports. Therefore during migration nova needs to query neturon about the
resource requests to include them to the allocation_candidates query
sent to placement during scheduling. Also when the allocation is made by
the scheduler nova needs to re-calculate request group - resource
provider mapping. A subsequent patch will use this mapping to update the
binding profile when the port is bound to the destination host of the
migration.
blueprint: support-move-ops-with-qos-ports
Change-Id: I8e5a0480c81ba548bc1f50a8098eabac52b11453
To be able to fill the allocation key in the port binding:profile during
the move operations the nova-compute needs to get the RequestSpec object
to have access to the port - resource provider mapping calculated in the
conductor.
This patch bumps the compute RPC api version and adds a new request_spec
parameter to multiple calls. Also it makes sure that the request_spec is
passed by the sender.
Change-Id: If1f465112b8e9b0304b8b5b864b985f72168d839
blueprint: support-move-ops-with-qos-ports
During migration conductor needs to heal the content of the
RequestSpec.requested_resources field based on the resource requests of
the ports attached to the instance being migrated.
This patch makes sure that the MigrationTask has access the networking
API to do such healing.
blueprint: support-move-ops-with-qos-ports
Change-Id: Idf38568c3c237687c54fbbfcc6c5792c49c95161
This patch adds a new network api method
get_requested_resource_for_instance() to query neutron about the
resource needs of the ports currently bound to an instance. A later
patch will use this to properly allocate resource for the ports during
migration.
blueprint: support-move-ops-with-qos-ports
Change-Id: I56ea5ee94139dfa2cdf6bb76656bca2902e7ea9c
Changes in [1] could potentially break a mixed-compute-version
environment as we don't have grenade coverage for cold migrate and
resize. This adds that coverage to the nova-grenade-multinode
job.
[1]https://review.opendev.org/#/c/655721/10
Change-Id: I81372d610ddf8abb473621deb6e7cb68eb000fee
We are planning to add non-live-migration multinode tests to this job
so first we rename it to be more generic.
Change-Id: I7571ff508fcccba40cf2307a8788c1850d2d9fd8
Some unit tests were performing string matches on xml data
with inputs that were generated using lxml. This is problematic
as while white space between element tags is important in xml
ordering of attributes within a tag is not. In the latest version
of lxml the ordering asserted in the test no longer matches the
order returned by lxml on python 3.6+.
This change updates the failing test to use the XMLMatcher
class to compare xml strings instead.
Closes-Bug: #1838666
Related-Bug: #1841667
Change-Id: I1649a850ccb9ac85d7a962936ffef51d573b6f78
Add code to init_host() in the libvirt driver which detects support
for AMD SEV in the compute host hardware and hypervisor, by checking
that:
a) 'sev' parameter of the kvm-amd kernel module is enabled, and
b) the <features> element returned from libvirt's
virConnectGetDomainCapabilities API contains an
<sev supported='yes'>
element. This second check is achieved by utilising the domain
capability retrieval and parsing code which was added in
I4c35b6a27db05349213429422ffe62adb09bd921.
When both checks pass, provide the standard trait HW_CPU_X86_AMD_SEV
(which was newly available in os-traits 0.13.0) on the resource
provider for the compute host. This indicates the ability of the
compute host to boot instances with AMD SEV (Secure Encrypted
Virtualization) enabled.
Note that this is not the last of the detection code. Future commits
will add support for the use of a new MEM_ENCRYPTION_CONTEXT resource
class in the compute host inventory which tracks how many guests with
encrypted memory can be run on a host concurrently. Until that point,
SEV functionality cannot be used, and this trait is effectively
dormant.
blueprint: amd-sev-libvirt-support
Change-Id: I2b41f1cce0af8b9d36b74a4663aa4ff227e17cc6