The PowerVM driver was deprecated in November 2021 as part of change
Icdef0a03c3c6f56b08ec9685c6958d6917bc88cb. As noted there, all
indications suggest that this driver is no longer maintained and may be
abandonware. It's been some time and there's still no activity here so
it's time to abandon this for real.
This isn't as tied into the codebase as the old XenAPI driver was, so
removal is mostly a case of deleting large swathes of code. Lovely.
Change-Id: Ibf4f36136f2c65adad64f75d665c00cf2de4b400
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
In order to support remote-managed ports the following is needed:
* Nova compute driver needs to support this feature;
* For the Libvirt compute driver, a given host needs to have the right
version of Libvirt - the one which supports PCI VPD (7.9.0
https://libvirt.org/news.html#v7-9-0-2021-11-01).
Therefore, this change introduces a new capability to track driver
support for remote-managed ports.
Change-Id: I7ea96fd85d2607e0af0f6918b0b45c58e8bec058
As with the vmwareapi driver back in Ussuri [1], our indications suggest
that this driver is no longer maintained and may be abandonware. Start
the deprecation timer for the driver. If we see signs of life, we can
re-assess this decision.
[1] Ie39e9605dc8cebff3795a29ea91dc08ee64a21eb
Change-Id: Icdef0a03c3c6f56b08ec9685c6958d6917bc88cb
This patch addresses outstanding nits from the bp/pci-socket-affinity
series. The most important is how the libvirt driver handles reporting
the new COMPUTE_SOCKET_PCI_NUMA_AFFINITY trait. Previously, this was
done by directly adding the trait in static_traits(). This patch
switches it to use driver capabilities.
Change-Id: I89d742ae01d65ab4e16fd8bd86b761f4c5d54d54
Currently only the Hyper-V driver supports this, so that's the only
thing that will report True. Future changes will extend this
functionality to libvirt.
Blueprint: allow-secure-boot-for-qemu-kvm-guests
Change-Id: I314f50a253317b6d80e1fcdd1b5932534841c57f
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Replace six.text_type with str.
A subsequent patch will replace other six.text_type.
Change-Id: I23bb9e539d08f5c6202909054c2dd49b6c7a7a0e
Implements: blueprint six-removal
Signed-off-by: Takashi Natsume <takanattie@gmail.com>
Remove references to the feature from various comments scattered
throughout the code.
Change-Id: Ic353a2489389c557859c249218eaf6060974e1a9
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
If we have instances requesting vTPM configuration, but not vTPM support
configured, we should crash and burn.
Part of blueprint add-emulated-virtual-tpm
Change-Id: I4f4446a0b52c3afca9e63a1882e7375c316dc30e
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This change introduces and checks the COMPUTE_RESCUE_BFV trait that was
introduced in os-traits 2.2.0 in the compute layer during an instance
rescue when the instance boots from a volume.
An additional kwarg ``allow_bfv_rescue`` flag is also added to the
signature of the rescue method within the compute API. This defaults to
False and will be used in a following change to indicate when the
request is using a high enough microversion to invoke this new
capability.
The ``supports_bfv_rescue`` capability tracked within the virt drivers
that this trait maps to is only added to the powervm driver for now due
to the way in which these capabilities are checked by the
``TestPowerVMDriver.test_driver_capabilities`` test.
Implements: blueprint virt-bfv-instance-rescue
Change-Id: Ic2ad1468d31b7707b7f8f2b845a9cf47d9d076d5
. Do not delete accelerator requests in stop code paths.
. In the start code path, get the list of accelerator requests from
Cyborg in the compute manager 'power_on'.
. Pass accel_info (said list) to the virt driver power_on.
. In libvirt driver, pass that accel_info to driver power_on.
Change-Id: I8c94504b87aa4450d163fe2b33f6aa0eb5dae5ff
Blueprint: nova-cyborg-interaction
Update the signature of the spawn() API for each virt driver
to include accel_info, which is a list of accelerator requests.
Change-Id: I4aac66c125a162bf35991a7d0c2638c7475ec0e7
Blueprint: nova-cyborg-interaction
Required by an upcoming bugfix to the Libvirt driver's implementation of
extend_volume that will require external authenticated calls to Cinder
and Barbican.
Change-Id: I0ef84dd0a6c3f1788caf7d3a8e3837203f6d5429
This doesn't exist for 'nova.volume' and no longer exists for
'nova.network'. There's only one image backend we support, so do like
we've done elsewhere and just use 'nova.image.glance'.
Change-Id: I7ca7d8a92dfbc7c8d0ee2f9e660eabaa7e220e2a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Strip out everything matching '(is|use)_neutron', except the tests for
nova-network code and two other places that these tests rely on. Along
the way, remove a whole load of apparently unnecessary mocking that
clearly wasn't caught when we switched over the bulk of testing to use
the neutron network driver.
Change-Id: Ifa9c5c468400261a5e1f66b72c575845173a4f8f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
A future change will bump flake8 to 3.x. See off most of the issues that
this will introduce now, with the exception of some missing typing
imports in 'nova/virt/hardware.py' - fixing those here with the current
version of flake8 would actually raise an error about unused imports.
Change-Id: I9480ac1749d448efe4f415f5e80ff9b9837216b6
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
In Train [1] we deprecated support for compute drivers
that did not implement the update_provider_tree method.
That compat code is now removed along with the get_inventory
method definition and (most) references to it.
As a result there are more things we can remove but those
will come in separate changes.
[1] I1eae47bce08f6292d38e893a2122289bcd6f4b58
Change-Id: Ib62ac0b692eb92a2ed364ec9f486ded05def39ad
We want to make sure people who have both pinned and unpinned instances
on a host (yes, it's dumb, but it happens) won't do a straightforward
'vcpu_pin_set' -> '[compute] cpu_dedicated_set' or '[compute]
cpu_shared_set' transition, breaking their ability to restart or rebuild
instances. We add a new 'supports_pcpus' driver capability to avoid
needing to do this on drivers that don't support PCPUs and CPU pinning
in general.
Change-Id: Ia1b3ab0b66fdaf569f6c7a09510f208ee28725b2
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
For a cross-cell resize, the equivalent of the "finish_resize"
method on the destination compute is going to call the
driver spawn() method rather than the finish_migration()
method and needs to pass through the power_on value, similar
to finish_migration, so that when resizing a stopped server
it remains stopped once it is resized.
The finish_migration method in the driver behaves very similar
to spawn so the semantics are the same.
This change updates the spawn method signature for all in-tree
compute drivers but only implements the logic for the libvirt
driver as that is the only driver (currently) which supports
cross-cell resize (note the can_connect_volume method is also
necessary for cross-cell resize implementation in the driver).
Part of blueprint cross-cell-resize
Change-Id: I6929c588dd2e0e805f2e30b2e30d29967469d756
This makes the base virt driver define capability flags for each of the
glance-defined image types. It also adds a capability-to-trait mapping
for each, causing any driver that supports a given image type to expose
the corresponding trait.
Related to blueprint request-filter-image-types
Change-Id: Id2912a46dddee3d63ce373e4d280fad79d0128a8
We always import privsep modules like this:
import nova.privsep.libvirt
Not like this:
from nova.privsep import libvirt
This is because it makes it obvious at the caller that a priviledged
operation is occuring:
nova.privsep.libvirt.destroy_root_filesystem()
Not just:
libvirt.destroy_root_filesystem()
This is especially true when the imported module is called "libvirt",
which is a very common term in the codebase and super hard to grep
for specific uses of.
I've corrected the existing style mismatches to make things consistent.
Note that the next patch in this series covers this case with a
hacking check.
Change-Id: Ief177dbcb018da6fbad13bb0ff153fc47292d5b9
Implement support for extending RBD attached volumes using the libvirt
network volume driver.
This adds a new parameter "requested_size" to the extend_volume method.
This is necessary because the new volume size can not be detected by
libvirt for network volumes. All other volume types currently
implementing the extend_volume call have a block device on the
hypervisor which needs to be updated and can be polled for it's new
size. For network volumes no such block device exists.
Alternatively this could be implemented without a new parameter by
calling into Ceph using os_brick to get the new size of the volume.
This would make the LibvirtNetVolumeDriver Ceph specific.
This also extends the logic to get the device_path for extending volumes
in the libvirt driver. This is necessary as network volumes don't have
the device path in the connection_info. The device_path is retrieved by
matching the connection_info serial (= volume UUID) against all guest
disks.
Co-Authored-By: Jose Castro Leon <jose.castro.leon@cern.ch>
Blueprint: extend-in-use-rbd-volumes
Change-Id: I5698e451861828a8b1240d046d1610d8d37ca5a2
We return cached data to sync_power_state to avoid pummeling the ironic
API. However, this can lead to a race condition where an instance is
powered on, but nova thinks it should be off and calls stop(). Check
again without the cache when this happens to make sure we don't
unnecessarily kill an instance.
Closes-Bug: #1815791
Change-Id: I907b69eb689cf6c169a4869cfc7889308ca419d5
When an admin creates a snapshot of another project owners
instance, either via the createImage API directly, or via the
shelve or createBackup APIs, the admin project is the owner
of the image and the owner of the instance (in another project)
cannot "see" the image. This is a problem, for example, if an
admin shelves a tenant user's server and then the user tries to
unshelve the server because the user will not have access to
get the shelved snapshot image.
This change fixes the problem by leveraging the sharing feature [1]
in the v2 image API. When a snapshot is created where the request
context project_id does not match the owner of the instance project_id,
the instance owner project_id is granted sharing access to the image.
By default, this means the instance owner (tenant user) can get the
image directly via the image ID if they know it, but otherwise the image
is not listed for the user to avoid spamming their image listing. In the
case of unshelve, the end user does not need to know the image ID since
it is stored in the instance system_metadata. Regardless, the user could
accept the pending image membership if they want to see the snapshot
show up when listing available images.
Note that while the non-admin project has access to the snapshot
image, they cannot delete it. For example, if the user tries to
delete or unshelve a shelved offloaded server, nova will try to
delete the snapshot image which will fail and log a warning since
the user does not own the image (the admin does). However, the
delete/unshelve operations will not fail because the image cannot
be deleted, which is an acceptable trade-off.
Due to some very old legacy virt driver code which started in the
libvirt driver and was copied to several other drivers, several virt
drivers had to be modified to not overwrite the "visibility=shared"
image property by passing "is_public=False" when uploading the image
data. There was no point in the virt drivers setting is_public=False
since the API already controls that. It does mean, however, that
the bug fix is not really in effect until both the API and compute
service code has this fix.
A functional test is added which depends on tracking the owner/member
values in the _FakeImageService fixture. Impacted unit tests are
updated accordingly.
[1] https://developer.openstack.org/api-ref/image/v2/index.html#sharing
Change-Id: If53bc8fa8ab4a8a9072061af7afed53fc12c97a5
Closes-Bug: #1675791
With the extraction of placement we ended up with resource class names
being duplicated between nova and placement. To address that, the
os-resource-classes library [1] was created to provide a single
authority for standard resource classes and the format of custom
classes.
This patch changes nova to use it, removing the use of the rc_fields
module which used to have the information. A method left in it
(normalize_name) has been moved to utils.py, renamed as
normalize_rc_name, and callers and tests updated accordingly.
Because the placement code is being kept in nova for the time being,
that code's use of rc_fields is maintained, and the module too.
A note is added in the module explain that. Backporting the changes
from extracted-placement to placement-in-nova was considered but
because we no longer have placement tests in nova, that didn't seem
like the right thing to do.
requirements and lower-constraints have been updated.
os-resource-classes is already in global requirements.
For reference the related placement change is at [2].
[1] https://docs.openstack.org/os-resource-classes
[2] https://review.openstack.org/#/c/623556/
Change-Id: I8e579920c0eaca81b563a87429c930b21b3d4dc5
There were a bunch of report client methods around updating inventory to
placement which were only being used in the non-update_provider_tree
code paths of the resource tracker's update routine. Those code paths
had already been retrofitted to produce a placement-shaped inventory
object.
update_from_provider_tree gives us another way to flush these inventory
changes.
This patch simply takes the inventory object produced by the
get_inventory() and update_compute_node() code paths and updates the
provider tree object in the same fashion as update_provider_tree does.
So now all three code paths can commonly invoke
update_from_provider_tree.
And we can get rid of a ton of redundant code in the report client.
This includes the former incarnation of set_inventory_for_provider; so
we rename the artist formerly known as _set_inventory_for_provider to
match its brethren, set_traits_for_provider and
set_aggregates_for_provider.
Change-Id: I1a305847f0310c8d4babd5a625e4cc7bffe5b086
This patch adds new ``initial_xxx_allocation_ratio`` CONF options
and modifies the resource tracker's initial compute node creation to
use these values.
During the update_available_resource periodic task, the allocation
ratios reported to inventory for VCPU, MEMORY_MB and DISK_GB will
be based on:
* If CONF.*_allocation_ratio is set, use it. This overrides everything
including externally set allocation ratios via the placement API.
* If reporting inventory for the first time, the
CONF.initial_*_allocation_ratio value is used.
* For everything else, the inventory reported remains unchanged which
allows operators to set the allocation ratios on the inventory records
in placement directly without worrying about nova-compute overwriting
those changes.
As a result, several TODOs are removed from the virt drivers that
implement the update_provider_tree interface and a TODO in the resource
tracker about unset-ing allocation ratios to get back to initial values.
Change-Id: I14a310b20bd9892e7b34464e6baad49bf5928ece
blueprint: initial-allocation-ratios
The PowerVM patch to implement the update_provider_tree method (in a
fashion backward compatible with the existing get_available_resource
method) [1] was in flight at the same time as a
bp reshape-provider-tree patch introducing the 'allocations' kwarg [2]
and another patch which provided a ComputeDriver helper method for
calculating the reserved value for the DISK_GB resource from config [3].
This brings PowerVM's update_provider_tree method up to scratch with
those changes.
[1] I96da858e6a63e3339a009fd17ee0d8939b364510
[2] Ic062446e5c620c89aec3065b34bcdc6bf5966275
[3] I72c83a95dabd581998470edb9543079acb6536a5
Change-Id: I89ad36f19672368a1f795e1f29c5af6368ccfeec
Implement the update_provider_tree ComputeDriver method in the
PowerVMDriver.
In this patch, we *just* implement it to be backward compatible with how
the resource tracker populates the compute node resource provider
inventory based on get_available_resource. Future patches will bring
sanity to such values as allocation_ratio, min_unit, and reserved.
Future patches (as part of larger efforts) will also handle providers
and/or inventories for SR-IOV, devices, etc.
Change-Id: I96da858e6a63e3339a009fd17ee0d8939b364510
There are potential security issues with using predictable temp
directories or files, so use python's tempfile module to do this
safely.
Change-Id: Ia067236785882ad3acca23a425ea1333b247d8c6
Closes-Bug: #1771538
The docstring for PowerVM's DiskAdapter.get_bootdisk_patch method was
giving incorrect information about its purpose and return value. This
fixes that.
Change-Id: I0a7658ac339dbc52f6bd6465d0e9bebcb75b8528
This makes the libvirt driver handle and pass trusted_certs through to
the image download code that is now available.
This also adds a new supports_trusted_certs compute driver capability
which only the libvirt driver supports at this time. Attempts to
create a server or rebuild a server on a host with a driver that does
not support trusted_certs will fail if the instance is requesting
image cert validation. We can also eventually expose this capability
as a trait for more efficient scheduling.
The nova-compute service RPC API version is incremented so that the
nova-api paths for create/rebuild can determine if the deployment
has been upgraded to the point of supporting trusted certs.
Co-Authored-By: Dan Smith <dansmith@redhat.com>
Co-Authored-By: Brianna Poulos <Brianna.Poulos@jhuapl.edu>
Change-Id: Ie3130e104d7ca80289f1bd9f0fee9a7a198c263c
Implements: blueprint nova-validate-certificates
This change adds vSCSI Fibre Channel volume support via cinder for the
PowerVM virt driver. Attach, detach, and extend are the supported
volume operations by the PowerVM vSCSI FC adapter. PowerVM CI volume
tests are run on-demand only which can be done by leaving a comment
with "powervm:volume-check".
Blueprint: powervm-vscsi
Change-Id: I632993abe70f9f98a032a35891b690db15ded6a0
This patch cleans up some nits left after the merge of [1].
- Uses mock_open() in test_stream_blockdev_to_glance
- Removes errant quote in InstanceDiskToMgmt() header
- Fixes method header for generate_snapshot_metadata()
[1] https://review.openstack.org/#/c/543023/
Change-Id: Iba75282db968f74ac2e4474c872ba59f9cd77652
This adds the DiskAdapter parent class for PowerVM disk adapters. The
only disk adapter currently supported by the PowerVM virt driver is
shared storage pool. However adding additional PowerVM disk adapters
(localdisk) will be simplified by implementing the base class first.
Blueprint: powervm-localdisk
Change-Id: Id3a2a1df3746120af38b62fdc902c3c0c44c38ee
Stephen Finucane