This adds a microversion and API support for triggering a rebuild
of volume-backed instances by leveraging cinder functionality to
do so.
Implements: blueprint volume-backed-server-rebuild
Closes-Bug: #1482040
Co-Authored-By: Rajat Dhasmana <rajatdhasmana@gmail.com>
Change-Id: I211ad6b8aa7856eb94bfd40e4fdb7376a7f5c358
This patch adds support for passing the ``reimage_boot_volume``
flag from the API layer through the conductor layer to the
computer layer and also includes RPC bump as necessary.
Related blueprint volume-backed-server-rebuild
Change-Id: I8daf177eb67d08112a16fe788910644abf338fa6
This patch adds the plumbing for rebuilding a volume backed
instance in compute code. This functionality will be enabled
in a subsequent patch which adds a new microversion and the
external support for requesting it.
The flow of the operation is as follows:
1) Create an empty attachment
2) Detach the volume
3) Request cinder to reimage the volume
4) Wait for cinder to notify success to nova (via external events)
5) Update and complete the attachment
Related blueprint volume-backed-server-rebuild
Change-Id: I0d889691de1af6875603a9f0f174590229e7be18
During a normal update_available_resources run if the local provider
tree caches is invalid (i.e. due to the scheduler made an allocation
bumping the generation of the RPs) and the virt driver try to update the
inventory of an RP based on the cache Placement will report conflict,
the report client will invalidate the caches and the retry decorator
on ResourceTracker._update_to_placement will re-drive the top of the
fresh RP data.
However the same thing can happen during reshape as well but the retry
mechanism is missing in that code path so the stale caches can cause
reshape failures.
This patch adds specific error handling in the reshape code path to
implement the same retry mechanism as exists for inventory update.
blueprint: pci-device-tracking-in-placement
Change-Id: Ieb954a04e6aba827611765f7f401124a1fe298f3
It is a simple refactor to move the actual RP creation under the scope
of PciResourceProvider.update_provider_tree to remove the assumption the
RPs are always pre-created by the caller in the provider_tree.
blueprint: pci-device-tracking-in-placement
Change-Id: I375a1fb013a8e877c159b907484ba16871935879
We don't support enabling and then later disabling
[pci]report_in_placement. This patch adds a check that kills the
nova-compute service is such situation.
The implementation rely on an extra trait
COMPUTE_MANAGED_PCI_DEVICE that is added to every PCI RP
automatically. Note that we cannot use the existing OWNER_NOVA standard
trait as that will be exists on other RPs in RP three. Also we cannot
use the naming scheme of the PCI RPs as cyborg is free to use the same
scheme and also nova might want to use that for VGPUs / MDEVs in the future.
Depends-On: https://review.opendev.org/c/openstack/os-traits/+/850538
blueprint: pci-device-tracking-in-placement
Change-Id: I6e68d7754cee51525894c14a74a554d82a648d8d
Device addition, removal and reconfiguration (i.e. changing
resource_class or traits) are supported now. Note that as scheduling
support is not yet added testing reconfiguration while there are
allocations against the reconfigured devices is not tested yet.
blueprint: pci-device-tracking-in-placement
Change-Id: I31b94598516e97d1653aed6edfd3d19c67782a4a
We agreed not to support 'devname' based [pci]device_spec configuration
in the new PCI Placement tracking code. So this patch adds a check to
reject those.
blueprint: pci-device-tracking-in-placement
Change-Id: Ifa0dd34506ebc25cfe5bafd6952b72b0008fc741
The first version of the PCI tracking in placement feature will not
handle Neutron based SRIOV devices. So those are now ignored during
placement inventory reporting.
blueprint: pci-device-tracking-in-placement
Change-Id: Ie24969d60c84379673c5450863f4cf58cf09207c
If two VFs from the same PF are configured by two separate
[pci]device_spec entries then it is possible to define contradicting
resource classes or traits. This patch detects and rejects such
configuration.
blueprint: pci-device-tracking-in-placement
Change-Id: I623ab24940169991a400eba854c9619a11662a91
The PCI tracking in placement does not support the configuration where
both a PF and its children VFs are configured for nova usage. This patch
adds logic to detect and reject such configuration. To be able to kill
the service if started with such config special exception handling is
added for the update_available_resource code path, similarly how a
failed reshape is handled.
blueprint: pci-device-tracking-in-placement
Change-Id: I708724465d2afaa37a65c231c64da88fc8b458eb
Each [pci]device_spec entry can specify the two new resource_class and
traits tags.
If the resource_class is specified then it will be used as the RC in the
placement inventory of the PCI devices matching the spec. If not
specified then the RC is defaulted CUSTOM_PCI_<vendor_id>_<product_id>.
The traits tag is a comma separated list of trait names. Nova will
report these traits to RP representing the matching PCI devices.
blueprint: pci-device-tracking-in-placement
Change-Id: I71b7a2fb8b03a3679733a98958b2f6d447ed5004
A new PCI resource handler is added to the update_available_resources
code path update the ProviderTree with PCI device RPs, inventories and
traits.
It is a bit different than the other Placement inventory reporter. It
does not run in the virt driver level as PCI is tracked in a generic way
in the PCI tracker in the resource tracker. So the virt specific
information is already parsed and abstracted by the resource tracker.
Another difference is that to support rolling upgrade the PCI handler
code needs to be prepared for situations where the scheduler does not
create PCI allocations even after some of the compute already started
reporting inventories and started healing PCI allocations. So the code
is not prepared to do a single, one shot, reshape at startup, but
instead to do a continuous healing of the allocations. We can remove
this continuous healing after the PCI prefilter will be made mandatory
in a future release.
The whole PCI placement reporting behavior is disabled by default while
it is incomplete. When it is functionally complete a new
[pci]report_in_placement config option will be added to allow enabling
the feature. This config is intentionally not added by this patch as we
don't want to allow enabling this logic yet.
blueprint: pci-device-tracking-in-placement
Change-Id: If975c3ec09ffa95f647eb4419874aa8417a59721
The PciPassthroughFilter logic checks each InstancePCIRequest
individually against the available PCI pools of a given host and given
boot request. So it is possible that the scheduler accepts a host that
has a single PCI device available even if two devices are requested for
a single instance via two separate PCI aliases. Then the PCI claim on
the compute detects this but does not stop the boot just logs an ERROR.
This results in the instance booted without any PCI device.
This patch does two things:
1) changes the PCI claim to fail with an exception and trigger a
re-schedule instead of just logging an ERROR.
2) change the PciDeviceStats.support_requests that is called during
scheduling to not just filter pools for individual requests but also
consume the request from the pool within the scope of a single boot
request.
The fix in #2) would not be enough alone as two parallel scheduling
request could race for a single device on the same host. #1) is the
ultimate place where we consume devices under a compute global lock so
we need the fix there too.
Closes-Bug: #1986838
Change-Id: Iea477be57ae4e95dfc03acc9368f31d4be895343
While discussing the new RBAC (scope_type and project admin vs
system admin things) with operators in berlin ops meetup and
via emails, and policy popup meetings, we got the feedback that
we need to keep the legacy admin behaviour same as it is otherwise
it is going to be a big breaking change for many of the operators.
Same feedback for scope_type.
- https://etherpad.opendev.org/p/BER-2022-OPS-SRBAC
- https://etherpad.opendev.org/p/rbac-operator-feedback
By considering the feedback, we decided to postpone the
system scope implementation, release project reader
role and not to change the legacy admin behaviour.
To keep the legacy admin behaviour unchanged, we need to
modify our policy new default so that legacy admin continue
to have the access to the APIs they are able to access in
old RBAC. Basically the below changes:
- PROJECT_ADMIN -> ADMIN (legacy admin who can do things in all projects)
- PROJECT_MEMBER -> PROJECT_MEMBER_OR_ADMIN (give access to legacy admin too)
- PROJECT_READER -> PROJECT_READER_OR_ADMIN (give access to legacy admin too)
Complete direction on RBAC is updated in community wide goal
- https://review.opendev.org/c/openstack/governance/+/847418/13
Change-Id: I37e706f75a36fb27da1bdd5fba671cb1bcadc745
This change adds a new hw:locked_memory extra spec and hw_locked_memory
image property to contol preventing guest memory from swapping.
This change adds docs and extend the flavor
validators for the new extra spec.
Also add new image property.
Blueprint: libvirt-viommu-device
Change-Id: Id3779594f0078a5045031aded2ed68ee4301abbd
In line with the recent RBAC working group discussion and operator
feedback, this converts all our APIs back to project-only. It leaves
the actual scope_types in place, with them all set to project. This
allows an operator to turn on scope checking to *ensure* that only
project-scoped tokens are used, in case system scope is in use
elsewhere in the deployment (i.e. for keystone or ironic). Without
this, system scoped tokens will fail some operations in strange
(read: 500 and "database error") ways.
Change-Id: I951a11affa1d1e42863967cdc713618ff0a74814
This reverts commit a669f9150a.
Reason for revert: The test is unstable. This patch actually failed the check queue one 877f0e19083e47968b3fc12cae82eba3 but was rechecked and merged. The enabled testcase now failing in the gate frequently: https://paste.opendev.org/show/bDiRRVFsYa5MAND6Bhjm/
Change-Id: Ieb1ca2ea647c25e64e5a9f72402195469349695a
This change append vnic-type vdpa to the list
of passthough vnic types and removes the api blocks
This should enable the existing suspend and live migrate
code to properly manage vdpa interfaces enabling
"hot plug" live migrations similar to direct sr-iov.
Implements: blueprint vdpa-suspend-detach-and-live-migrate
Change-Id: I878a9609ce0d84f7e3c2fef99e369b34d627a0df
change I3a45b1fb41e8e446d1f25d7a1d77991c8bf2a1ed
tried to fix bug #1563874 by using _detach_pci_device
to remove hostdev pci devices however that breaks
other usecase so we attempt to fix that by only
calling _detach_pci_device for devices it can
handle and use detach_interface for the rest.
Related-bug: #1563874
Related-bug: #1970467
Change-Id: I351d58d6922ca169b641500c12ffd6f91829df90
This change extends the guest xml parsing such that
the source device path can be extreacted from interface
elements of type vdpa.
This is required to identify the interface to remove when
detaching a vdpa port from a domain.
This change fixes a latent bug in the libvirt fixutre
related to the domain xml generation for vdpa interfaces.
Change-Id: I5f41170e7038f4b872066de4b1ad509113034960
Alphabetizes objects as suggested in the code comment.
This change was part of the manila virtiofs series.
But as indicated by gibi, this part is now an individual patch to not
mix topics and makes the initial patch easier to read.
Change-Id: I765ff142b2b4b6beffa35d5fc2a9985907307640
Fix the following deprecation warning.
* DeprecationWarning: setDaemon() is deprecated,
set the daemon attribute instead
Change-Id: I208bd1bef002ce91e57798f3475bbe64d3b81329
Closes-Bug: 1987191
Signed-off-by: Takashi Natsume <takanattie@gmail.com>
It does not need anymore to add database migration placeholders
because of using alembic.
So remove the description in the PTL guide.
Change-Id: If958dd78ff82e2239be1af3835a51a1a3551c5d9
Signed-off-by: Takashi Natsume <takanattie@gmail.com>
Dan Smith