When a user calls the volume-update API, we swap_volume in the libvirt
driver from the old volume attachment to the new volume attachment.
Currently, we're saving the domain XML with the old configuration prior
to updating the volume and upon a soft-reboot request, it results in an
error:
Instance soft reboot failed: Cannot access storage file <old path>
and falls back to a hard reboot, which is like pulling the power cord,
possibly resulting in file system inconsistencies.
This changes to saving the new, updated domain XML after the volume
swap.
Closes-Bug: #1713857
Change-Id: I166cde5ad8b00699e4ec02609f0d7b69236d855d
Adds initial support for storing the relationship between parent and
child resource providers. Nested resource providers are essential for
expressing certain types of resources -- in particular SR-IOV physical
functions and certain SR-IOV fully-programmable gate arrays. The
resources that these providers expose are of resource class
SRIOV_NET_VF and we will need a way of indicating that the physical
function providing these virtual function resources is tagged with
certain traits (representing vendor_id, product_id or the physical
network the PF is attached to).
The compute host is a resource provider which has an SR-IOV-enabled
physical function (NIC) as a child resource provider. The physical
function has an inventory containing some total amount of SRIOV_NET_VF
resources. These SRIOV_NET_VF resources are allocated to zero or more
consumers (instances) on the compute host.
compute host (parent resource provider)
|
|
SR-IOV PF (child resource provider)
:
/ \
/ \
VF1 VF2 (inventory of child provider)
The resource provider model gets two new fields:
- root_provider_uuid: The "top" or "root" of the tree of nested
providers
- parent_provider_uuid: The immediate parent of the provider, or None
if the provider is a root provider.
The database schema adds two new columns to the resource_providers
table that contain the internal integer IDs that correspond to the
user-facing UUID values:
- root_provider_id
- parent_provider_id
The root_provider_uuid field is non-nullable in the ResourceProvider
object definition, and this code includes an online data migration to
automatically populate the root_provider_id field with the value of the
resource_providers.id field for any resource providers already in the
DB.
The root_provider_id field value is populated automatically when a
provider is created. If the parent provider UUID is set, then the
root_provider_id is set to the root_provider_id value of the parent. If
parent is unset, root_provider_id is set to the value of the id
attribute of the provider being created. The corresponding UUID values
for root and parent provider are fetched in the queries that retrieves
resource provider data using two self-referential joins.
The root_provider_id column allows us to do extremely quick lookups of
an entire tree of providers without needing to perform any recursive
database queries.
Logic in this patch ensures that no resource provider can be deleted if
any of its children have any allocations active on them. We also check
to ensure that when created or updated, a resource provider's parent
provider UUID actually points to an existing provider.
It's important to point out that qualitative trait information is only
associated with a resource provider entity, not the resources that
resource provider has in its inventory. This is the reason why nested
resource providers are necessary. In the case of things like NUMA nodes
or SRIOV physical functions, if a compute host had multiple SRIOV
physical functions, each associated with a different network trait,
there would be no way to differentiate between the SRIOV_NET_VF
resources that those multiple SRIOV physical functions provided if the
containing compute host had a single inventory item containing the
total number of VFs exposed by both PFs.
Change-Id: I2d8df57f77a03cde898d9ec792c5d59b75f61204
blueprint: nested-resource-providers
Co-Authored-By: Moshe Levi <moshele@mellanox.com>
In the review of I49f5680c15413bce27f2abba68b699f3ea95dcdc, a few
non-blocking nits were identified. This change addresses some of
those nits, fixing some typos, clarifying method names and what
microversion is in use at particular times.
Change-Id: Iff15340502ce43eba3b98db26aa0652b1da24504
This provides microversion 1.13 of the placement API, giving the
ability to POST to /allocations to set (or clear) allocations for
more than one consumer uuid.
It builds on the recent work to support a dict-based JSON format
when doing a PUT to /allocations/{consumer_uuid}.
Being able to set allocations for multiple consumers in one request
helps to address race conditions when cleaning up allocations during
move operations in nova.
Clearing allocations is done by setting the 'allocations' key for a
specific consumer to an empty dict.
Updates to placement-api-ref, rest version history and a reno are
included.
Change-Id: I239f33841bb9fcd92b406f979674ae8c5f8d57e3
Implements: bp post-allocations
We currently don't record lock/unlock instance
actions. This is useful for auditing and debugging.
This patch adds instance lock/unlock actions.
Change-Id: I09fadf79aac1a74465af48015ef97d9e9d4ac580
partial-implements: blueprint fill-the-gap-for-instance-action-records
We currently don't record volume attach/detach/swap instance
actions. This is useful for auditing and debugging.
This patch adds volume attach/detach/swap actions.
Change-Id: I0a3d15f3e3d0d8d920a79b519e17e3228e99f293
partial-implements: blueprint fill-the-gap-for-instance-action-records
Commit 984dd8ad6a makes a rebuild
with a new image go through the scheduler again to validate the
image against the instance.host (we rebuild to the same host that
the instance already lives on).
The problem is that change introduced a regression where the
FilterScheduler is going to think it's doing a resize to the same
host and double the allocations for the instance (and usage for the
compute node provider) in Placement, which is wrong since the
flavor is the same.
This adds a regression test to show the bug.
Change-Id: Ie0949b4e6101f0b29ec4542146d523a07a683991
Related-Bug: #1664931
This aims to fix the issue described in bug 1664931 where a rebuild
fails to validate the existing host with the scheduler when a new
image is provided. The previous attempt to do this could cause rebuilds
to fail unnecessarily because we ran _all_ of the filters during a
rebuild, which could cause usage/resource filters to prevent an otherwise
valid rebuild from succeeding.
This aims to classify filters as useful for rebuild or not, and only apply
the former during a rebuild scheduler check. We do this by using an internal
scheduler hint, indicating our intent. This should (a) filter out
all hosts other than the one we're running on and (b) be detectable by
the filtering infrastructure as an internally-generated scheduling request
in order to trigger the correct filtering behavior.
Closes-Bug: #1664931
Change-Id: I1a46ef1503be2febcd20f4594f44344d05525446
New notifications service.create and service.delete are introduced
with INFO priority and the payload of the notification is the serialized
form of the already existing Service versioned object. Service.create
notification will be emitted after the service is created (so the uuid
is available) and also send the service.delete notification after the
service is deleted.
Implement blueprint: service-create-destroy-notification
Change-Id: I955d98f9fd4b121f98e172e5ab30eb668a24006d
DELETE assisted_volume_snapshots API accept 'delete_info'
query param.
This commit adds json schema to validate the valid
query parameters.
There is no change in API behaviour and additionalProperties
is kept True for backward compatibility.
Partially implements blueprint json-schema-validation-for-query-param
Change-Id: Ie1e81dfdb1e42af87725977c0f9504ea35ca9d70
Adds a simple ProviderSummary.resource_class_names @property that
returns a set() of resource class string names for all resources in the
provider summary. This allows a couple locations in the
_alloc_candidates_with_shared() function to be a little more readable.
Change-Id: I5ba492db3e38a3b560443780af82aef5105f13e1
Adds filtering on a set of required traits to the
AllocationCandidates._get_by_filters() method, for deployments with no
shared providers that are involved in the request.
This patch should demonstrate where I'm heading with the breaking out of
the various SQL-related pieces into their own functions. The next patch
will add required traits support for scenarios with sharing providers.
Change-Id: Iac246245ef7aedfa2d23e623f83fdf384e252159
This patch completes the refactoring of the
AllocationCandidates._get_by_filters() mega-method by splitting out the
remaining pieces of code that handle the construction of the
part-shared, part-non-shared allocation requests for when there are
sharing providers in a deployment.
The split-out _alloc_candidates_with_shared() is still a long, complex
method and I'll continue trying to reduce the complexity there and break
functions out of it further. I did uncomplicate a part of the function
with use of the itertools.product() function to replace a faulty use of
zip() against a list of allocation request resource lists.
Closes-Bug: #1730730
Change-Id: Ibcfd1a28f36d3c7ccd26fcc6386207e4a25300d4
This updates the config drive status to complete for PowerVM [1]. It
also updates the status for PowerVM features previously classified as
unknown.
[1] https://review.openstack.org/#/c/409404/
Change-Id: Idc5e40f2473d27c31c5a620ad9b93cce01dc7f85
GET flavor API accept query param to filter the
flavors.
This commit adds json schema to validate the valid
query parameters.
There is no change in API behaviour and additionalProperties
is kept True for backward compatibility.
Partially implements blueprint json-schema-validation-for-query-param
Change-Id: I61324ba58eddfed1445d7c70db761961e1b6a864
Zuul