This is so we don't have all the other objects imported into the
the placement process, which happens by virtue of being in the
nova.objects package. It also eases the eventual extraction of
placement.
That extraction will involve lifting and shifting the
nova/api/openstack/placement directory (plus any tests) to a new
repository. .../placement will become the roo placement directory
in the repo, since a) placement is (for now) only an API, b) it
eases extraction. Subsequent patches will do things like move
exceptions and the wsgi application.
Change-Id: I3e5144217c194f2571526311ddae6661cfed2ea9
Move the ResourceClass field to its own package, and move that package
to the top of the nova hierarchy since it is used by both nova tooling
and placement tooling but we don't want the placement version to have to
incorporate the nova code. Eventually we'd like to see an
os-resource-classes library, similar to os-traits, which will serve this
functionality. This is a step in that direction.
Changes in this patch are quite widespread, but are mostly only changes
of imports.
Change-Id: Iea182341f9419cb514a044f76864d6bec60a3683
Introduce placement microversion 1.18 with a new ?required=<trait list>
query parameter accepted on the GET /resource_providers API. Results
are filtered by providers possessing *all* of the specified traits.
Empty/invalid traits result in 400 errors.
Change-Id: I8191c9a390cb02b2a38a3f1c6e29457435994981
blueprint: traits-on-list-resource-providers
In the review for I5f3d4f49c34fd3cd6b9d2e12b3c3c4cdcb409bec some
non-blocking issues were identified. They are fixed here:
* inconsistent indentation in configuration setting
* creation of a uuid tracking set in the wrong block
Change-Id: I848d60f9a5d66cae584279f99a50b9e871540baf
This patch add new query parameter `required` to the
`GET /allocation_candidates` API, which is used to filter candidates
with required traits. The candidate attached traits return in the
provider summary also. Those API changes are added by new microversion.
Also using specific exception TraitNotFound instead of the generic
exception ValueError when invalid traits in the request.
Change-Id: Id821b5b2768dcc698695ba6570c6201e1e9a8233
Implement blueprint add-trait-support-in-allocation-candidates
Adds a utility function in nova/objects/resource_provider.py that
returns the set of root_provider_id values representing provider trees
that can COLLECTIVELY satisfy a request for resources.
Change-Id: I8ec2b4c9b0d48263ab13305d0550279bfa2dbe6f
blueprint: nested-resource-providers
Adds a simple _has_provider_trees() function to
nova/objects/resource_provider.py that returns True if any provider has
a non-NULL parent_provider_id. This will allow future code to take
simpler, optimized code paths when retrieving allocation candidates and
the deployment is not using nested resource providers.
Change-Id: I7305c8c00dd5595dcbfc9ea551da33677dbf38dd
blueprint: nested-resource-providers
Due to foreign key constraints for the
resource_provider.root_provider_id in mysql and the way of column
filling it is impossible to delete newly created RP now.
Patch sets root_provider_id to NULL before deletion
if root_provider_id == id.
Closes-Bug: #1739571
Co-Authored-by: Andrey Volkov <avolkov@mirantis.com>
Change-Id: I256c901fdc02b1f764ea9f8d1a1a708e82cc369a
Some resource providers were not in allocation candidates
because it is deleted during SQL query in get_all_with_shared()
function.
This patch changes get_all_with_shared() function not to use
conditions with non-existing parameter when outer-join tables.
By this change, bug-1705231 is fixed without considering the
order of INNER JOIN and OUTER JOINs.
Closes-Bug:#1705231
Related-Bug:#1731072
Change-Id: If8c1717c950a29b87cc22ea32d679a6289614067
Allocation candidates api returned some wrong
combinations of non-sharing resource provider and
shared resource provider, ignoring aggregates.
This patch adds aggregate check when constructing
shared allocation request being aware of non-sharing
resource in _shared_allocation_request_resources.
Change-Id: Ib45fde56706a861df0fc048bbec8a568fd26d85d
Closes-Bug:#1732707
In I3c7aea7d8959a20c3c404bc6616b47336ff40b67 a request was made
for clarifying documentation on the behavior of
AllocationList.create_all(). The database id is not set as a
ide-effect on the created objects.
Change-Id: I8a77a8146b6ec6babf5cb0897ed70fa3b2936b4e
The _set_allocations method used by AllocationList.create_all is
side-effecty: it sets the 'id' attribute on the list of Allocation
objects that is passed to it.
At the start of the method the incoming Allocation objects are
checked to see if they have already been created, by checking
for an 'id' field.
Meanwhile, _set_allocations is also configured to retry on db
deadlock. The deadlock can happen for a variety of reasons within
the transaction. The original theory, discussed in the original
fix, I2c276dc0125b5b9f7a54a1cd431b1b2f5239e93a, is that it is
during resource provider generation checks. In the associated bug it
looks like it may happen sometimes while inserting allocations.
In either case, if we have gone through the 'for alloc in allocs'
loop at least once, the contents of the 'allocs' list has been
modified to have at least one of the alloc.id fields set. Upon
retry, the 'id' field check at the start of the method will fail,
leading to an ObjectActionError and an eventual 500 at the placement
API level.
This change takes the simplest approach and simply removes the setting
of the 'id' attribute on the allocations in the 'allocs' list. There are
other ways to deal with this, this is the least intrusive. It works
because:
* create_all is only called from the allocation handler in placement,
and the objects are not used (the response bodies are empty)
* other than the 'id' change, the alloc members in the allocs list
are otherwise unchanged
* this kind of side-effecty business is dangerous, so let's not
rely on it
Tests which were relying on the side-effecty business have been adjusted
accordingly.
Change-Id: I3c7aea7d8959a20c3c404bc6616b47336ff40b67
Closes-Bug: #1739453
This adds a limit query parameter to GET
/allocation_candidates?limit=5&resource=VCPU:1
A 'limit' filter is added to the AllocationCandidates. If set, after
the database query has been run to create the allocation requests and
provider summaries, a slice or sample of the allocation requests is
taken to limit the results. The summaries are then filtered to only
include those in the allocation requests.
This method avoids needing to make changes to the generated SQL, the
creation of which is fairly complex, or the database tables. The amount
of data queried is still high in the extreme case, but the amount of
data sent over the wire (as JSON) is shrunk. This is a trade-off that
was discussed in the spec and the discussion surrounding its review.
If it turns out that memory use server-side is an issue we can
investigate changing the SQL.
A configuration setting, [placement]/randomize_allocation_candidates,
is added to allow deployers to declare whether they want the results
to be returned in whatever order the database chooses or a random
order. The default is "False" which is expected to preserve existing
behavior and impose a packing placement strategy.
When the config setting is combined with the limit parameter, if
"True" the limited results are a random sampling from the full
results. If "False", it is a slice from the front.
This is done as a new microversion, 1.16, with updates to docs, a reno
and adjustments to the api history doc.
Change-Id: I5f3d4f49c34fd3cd6b9d2e12b3c3c4cdcb409bec
Implements: bp allocation-candidates-limit
Some combinations of resource providers were duplicated in
allocation candidates.
This can happen when multiple sharing RPs are in the same aggregates,
because both sharing RPs visit each other during the algorithm to
see if it can be used as an allocation candidate's mate.
This patch adds to _alloc_candidates_with_shared() function a check
if we already have that combination in allocation candidates by
adding `alloc_prov_ids`, which is a list of sets of allocation
candidates's rp_ids.
Change-Id: Iefd3137ec68029d27081a743e52e327625585081
Closes-Bug:#1730730
Filtering allocation candidates on a set of required traits when there
are sharing providers in the deployment adds a lot of complexity. This
is just a simple fact of life, unfortunately. We have to play a sort of
game of scheduling Tetris whereby after we have grabbed the list of
resource providers that have access to local or shared inventory for
requested resources, we then need to ensure that the group of resource
providers that comprise the allocation request have ALL of the required
traits collectively between them.
This patch adds support for filtering allocation candidates by a set of
required traits when there are sharing providers in the deployment. The
code could still use additional cleanup, in particular there are areas
in the (now even larger) _alloc_candidates_with_shared() function that
do a lookup of a resource provider internal ID by traversing the list of
resource provider summaries looking for a resource provider by UUID.
These areas of the function should be refactored and a UUID -> ID lookup
hash created to remove this duplicate code.
Change-Id: Ia2295414654abf0e282926be6cd068189cd75352
We're seeing DBDeadlock failures during scheduling in CI jobs
when syncing traits when getting allocation candidates.
We have a lock around this code but that's not going to carry across
multiple processes, so we need to be able to retry on deadlock if
one occurs.
Change-Id: I6cf1793c1cbed18d850ec7e32b5b195e78cb4e68
Closes-Bug: #1738083
A variety of changes are required to allow the various entities
presented by the placement API to have last-modified times.
According to the HTTP 1.1 RFC headers last-modified headers SHOULD always
be sent and should have a tie to the real last modified time. If we do
send them, we need Cache-Control headers to prevent inadvertent caching
of resources.
This patch provides necessary changes to the database and object
handling that will support the API changes made in a followup patch.
The main steps are:
* map base.NovaTimestampObject to ovo.TimestampedObject
* Add the base.NovaTimestampObject mixin to the relevant object in
nova/objects/resource_provider.py
* Tweak queries to retrieve updated_at and created_at fields where
they are not already present
Note that only those objects which are directly represented in response
bodies and directly associated with a database resource that has
created_at and updated_at fields are changed (e.g., resource providers).
Other objects, like usage and allocaiton candidates, which are
composites and represent the state of the universe _now_, will use the
current time when they get last-modified headers in the next patch.
Some HTTP requests, such as GET /resource_providers/{uuid}/aggregates
are based on a association that happens at a time that is not recorded
and is ambiguous: should we tell last-modified time of the most recently
created aggregate uuid, or the time when the association between a
resource provider and an aggregate was made (which we don't know). In
those cases where a solution is unclear, no object or database changes
are made, and the next patch will use the current time in any related
last-modified headers.
Change-Id: I3f6310af9c5bea682e793d27d480952aa8776d61
Partial-Bug: #1632852
Partially-Implements: bp placement-cache-headers
Adds a new 'in_tree' filter parameter to the
ResourceProviderList.get_all_by_filters() method. This parameter allows
the caller to get providers in the "provider tree" of a supplied
provider UUID.
Change-Id: If35ee6a90ca0a999f6c4815e6f5e99d9962dcc46
blueprint: nested-resource-providers
When deleting a resource provider,
if there are traits on the resource provider,
a foreign key constraint error occurs.
So add deleting trait associations for the resource provider
(records in the 'resource_provider_traits' table)
when deleting the resource provider.
Change-Id: I6874567a14beb9b029765bf49067af6de17f2bd2
Closes-Bug: #1727719
In a number of places in resource_provider.py, we're checking for
DBDuplicateError after running conn.execute(). And "conn" is an
SQLAlchemy Connection object. The issue is that DBDuplicateError is not
an SQLAlchemy exception. Instead, it is an oslo_db-specific exception
that is used to mask differences between DB drivers that variably return
an OperationalError or an IntegrityError when a duplicate key is found
[1].
In practice, what this means is that all calling locations that use the
straight "conn.execute()" calling sequence cannot rely on catching
DBDuplicateError (because SQLAlchemy's Connection.execute() method will
never raise it). Instead, all of those calling locations needed to be
updated to use context.session.execute() instead. This allows
DBDuplicateError to be caught properly.
In addition, all the manual construction of transactions in
resource_provider.py that did:
with conn.begin()
needed to have those manual begin() calls removed. The reason is that
oslo_db's Session object (which is what is injected by the enginefacade
into the nova.context.RequestContext) automatically handles creation,
commit and rollback of transactions based on whether the source
entrypoint is a writer or reader context.
Closes-bug: #1731668
[1]: https://github.com/openstack/oslo.db/blob/stable/pike/oslo_db/sqlalchemy/exc_filters.py#L95-L153
Change-Id: Ic5860cbef4d47e847bb5f190526b5a8ea3c33298
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>
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
To support including project_id and user_id in the output of GET
/allocations/{consumer_uuid} adjust the
_get_allocations_by_consumer_uuid query to join the necessary tables to
get project_id and user_id information.
Note that this is done as outer joins because in order to support older
(but not much older) microversions we need to allow those fields to be
null.
_get_allocations_by_provider_id is not extended in the same way as we
do not yet have any immediate need for the information in GET
/resource_providers/{uuid}/allocations.
Change-Id: I59175fa51e9553f41c73a6bcd1a77a134e0b19e3
Partially-Implements: bp symmetric-allocations
Pulls some more code out of the AllocationCandidates._get_by_filters()
mega method into a separate function that constructs an
AllocationRequest for a single provider that provides all of the
resources being requested.
Change-Id: I0e0ad23bb1c4e836c87f43c1fffddef45b241b11
Continues the refactoring of the AllocationCandidates._get_by_filters()
mega-method. Breaks out code that constructs the
AllocationRequestResource objects for all resources that can be
satisfied by a sharing provider into a new module-level
_shared_allocation_request_resources() function.
Change-Id: Ie0641454009652fa40e0eb98bc18deaf391cc2d2
Continues the refactoring of the AllocationCandidates._get_by_filters()
mega-method by pulling two code sections out of _get_by_filters() that
built up a dict of provider summary dict information as well as
constructed the list of ProviderSummary objects that is returned from
_get_by_filters().
A new module-level function _build_provider_summaries() now performs the
construction of ProviderSummary objects from a list of supplied usage
dicts.
Change-Id: I145deac781c23a30af83e60f83f2c17b88b634c4
The AllocationCandidates._get_by_filters() method is a long, complex
mega-method. We want to detangle it and make the code in it
understandable and readable. The first step in this refactoring involves
renaming a few poorly-named variables, adding more code comments, and
breaking out the SQL for the most common code path (where no providers
share resources with other providers) into a separate module-level
function.
Change-Id: I716b279f719eb1fe26401a776344b976eca6587a
AllocationCandidates.get_by_filters used to take a `filter` parameter, a
dict with one member, 'resources'. Looking toward granular resource
requests (and other things like limiting the number of results), this
change set reworks the method (and its down-stack callees) to be named
get_by_requests. These now accept a `requests` parameter, which is a
list of RequestGroup instances parsed from the querystring via
parse_qs_request_groups.
The current patch is just a refactor. There is no API change, so the
schema will not allow anything other than the `resources` member of the
shared (use_same_provider=False) RequestGroup to come through. That
member is extracted and passed down the line, resulting in no functional
change.
Change-Id: I8d7ccf56aa75d9183626f736b62fba62e239a826
blueprint: granular-resource-requests
Breaks functions out of the _set_traits() function for deleting and
adding a set of trait identifiers to a resource provider. In the
process, reworks the _set_traits() function to just operate on internal
identifiers and not string names.
blueprint: de-orm-resource-providers
Change-Id: I5b448c3e9b5f7a259488dacabba093ea5a150298
Chris Dent