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
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
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
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
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
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
To be consistent with the other module-level functions that handle the
raw DB access and writes for resource provider-related data, this patch
moves the ResourceProvider._set_traits() @staticmethod to the module
scope. In addition to this move, we also remove the @remotable
decoration on the ResourceProvider.set_traits() instance method (since
no resource provider objects are sent over RPC) and we ensure that the
resource provider object itself resets changes after setting traits (since the
provider generation is incremented).
blueprint: de-orm-resource-providers
Change-Id: I7667a6a4cedfe8cc4abb0785530e0859fb0c8bcf
It had been on the AllocationList object but this makes it impossible to
have an AllocationList from multiple project ids. When it was decided to
allow setting allocations from multiple different consumers, it was
decided that since we were already in the code changing things, we
should also make adjustments to allow each allocation to have its own
project and user id.
In the process, ensure that if a persisted Allocation has a project_id
and user_id associated with it, load those values when the Allocation is
loaded (either list allocations by consumer or by resource provider).
We cannot enforce (at the object level) that Allocations must have a
project_id and user_id because there is a microversion where they are
not required that we continue to support. In newer microversions the
JSON schema enforces the their requirement.
Inspecting the placement fixtures related to this change revealed a bug
with a missing user_id in one Allocation being created.
Change-Id: I3cf887bd541c187ec3baca2ae3f8c16f1754e96e
Changes the AllocationList.get_by_resource_provider_uuid() to
AllocationList.get_by_resource_provider(), accepting a ResourceProvider
object parameter instead of a UUID. This is exactly how the
InventoryList object was changed in an earlier patch. A new
module-scoped _get_allocations_by_provider_id() function is added that
bypasses the ORM and uses the SQLAlchemy core expression API directly
to produce a smaller query with no joins.
blueprint: de-orm-resource-providers
Change-Id: Id866ab8353077cfeeae693c2958f412930f0f24d
Changes the implementation of the
InventoryList.get_all_by_resource_provider_uuid() method to streamline
the generated SQL for the query against the database and move the
@staticmethod out into module scope to be consistent with other DB
retrieval methods.
The get_all_by_resource_provider_uuid() interface is converted to a
get_all_by_resource_provider() interface, accepting a ResourceProvider
object instead of a UUID string. The reason for this is because all
calling locations of InventoryList.get_all_by_resource_provider_uuid()
were already calling ResourceProvider.get_by_uuid() and therefore
already had a ResourceProvider object that could be used to construct a
list of Inventory objects. Passing in this resource provider object
means we can eliminate the joins from inventories to resource_providers
table and the associated ORM costs.
blueprint: de-orm-resource-providers
Change-Id: I895114872a515a269487a683124b63303818e19c
The nova.objects.resource_provider.Inventory class was only intended to
be a plain-old data (POD) class and never intended to be able to
create, update or delete as a single item. Rather, the ResourceProvider
class has a set_inventory() method that accepts an InventoryList object
and operates on a set of inventory records as an atomic unit.
This patch removes the old, unused code paths that added CRUD
operations for the Inventory class, turning Inventory into a POD class.
blueprint: de-orm-resource-providers
Change-Id: Id8b182b3074122fc0bdbe201960e174b8f8d52f0
This patch series aims to remove the use of SQLAlchemy ORM querying
from the nova/objects/resource_provider.py module. Currently, there is
a mix of non-ORM (SQLAlchemy core expression API) and ORM (SQLAlchemy's
orm module and associated query generation from model reflection).
While implementing the database schema for the nested resource
providers table structure, which uses both an adjacency list model as
well as a cached root tree ID, it became obvious that using
the SQLAlchemy ORM modeling to generate the required queries for
various methods related to resource providers was resulting in awkward
and hard-to-reason-about code. Even using the recommended handling of
self-referential tables [1] for adjacency list modeling, the way the
session and querying handling was done in the resource_provider.py
module led to a number of lazy-loading problems and inactive session
errors.
In this starter patch, we tackle the ResourceProvider.get_by_uuid()
method, converting it to use the SQLAlchemy core expression API instead
of an ORM query.
[1] http://docs.sqlalchemy.org/en/latest/orm/self_referential.html
blueprint: de-orm-resource-providers
Change-Id: I2f14afa8fc01b0ec1b7ea3eaa0bf6c459a8681d2
Unregister the ResourceProvider object because we do not need
RPC and versioning for the objects in nova.objects.resource_provider.
There are two primary changes here:
* unregistering the ResourceProvider class
* where objects.ResourceProvider is used, point directly to the
nova.objects.resource_provider package instead
Partially-Implements: bp placement-deregister-objects
Change-Id: I564a4a10c9f07883025df70fecb1a59d547ef7ed
Unregister the Inventory object because we do not need RPC and
versioning for the objects in nova.objects.resource_provider.
There are two primary changes here:
* unregistering the Inventory class
* where objects.Inventory is used, point directly to the
nova.objects.resource_provider package instead
Partially-Implements: bp placement-deregister-objects
Change-Id: Ideca0f09f5dc4ba6bb194a2413ed93cf592dd963
Unregister the InventoryList object because we do not need RPC and
versioning for the objects in nova.objects.resource_provider.
There are two primary changes here:
* unregistering the InventoryList class
* where objects.InventoryList is used, point directly to the
nova.objects.resource_provider package instead
Partially-Implements: bp placement-deregister-objects
Change-Id: Ic11bbef4ccbf1f3df1d50837c49e8a4cbd4ba572
Unregister the Allocation object because we do not need RPC and
versioning for the objects in nova.objects.resource_provider.
There are two primary changes here:
* unregistering the Allocation class
* where objects.Allocation is used, point directly to the
nova.objects.resource_provider package instead
Partially-Implements: bp placement-deregister-objects
Change-Id: Ib026438b5f843fce848277347a95f3c4b6f94fb1
Unregister the AllocationList object because we do not need RPC and
versioning for the objects in nova.objects.resource_provider.
There are two primary changes here:
* unregistering the AllocationList class
* where objects.AllocationList is used, point directly to the
nova.objects.resource_provider package instead
Partially-Implements: bp placement-deregister-objects
Change-Id: I554380e9b427a6c12261929989536d95086b3e0b
Unregister the Usage object because we do not need RPC and versioning
for the objects in nova.objects.resource_provider.
There are two primary changes here:
* unregistering the Usage class
* where objects.Usage is used, point directly to the
nova.objects.resource_provider package instead
Partially-Implements: bp placement-deregister-objects
Change-Id: If40ef25c808cebd6e7a22a0b1697161eeadb30cb
Unregister the ResourceClass object because we do not need RPC
and versioning for the objects in nova.objects.resource_provider.
There are three primary changes here:
* unregistering the ResourceClass class
* where objects.ResourceClass is used, point directly to the
nova.objects.resource_provider package instead
* move the CUSTOM_NAMESPACE for resource class names to the the fields
object. This avoids an import loop and also makes more sense as
the field represents the name.
Partially-Implements: bp placement-deregister-objects
Change-Id: If537c786ea1a61383d82bad9a1de86c25c6cdbd2
Some functional tests were failing, due to standard traits not being
found. The cause was that there is a flag that ensures that these
standard traits are only loaded once from the os_traits module to the
DB. The test fixtures, though, would clean up the DB between runs, and
the traits would never be re-loaded. This patch fixes that by directly
resetting this flag in the base test code.
Closes-bug: #1701035
Change-Id: I5dc0220310986c5b9fe5b71013c573c3d98cb9aa
This method is no longer used, nor should it be. Instead, the
AllocationList.create_all() method should be used to create allocations
in the DB. Tests have been updated to use create_all() instead, and as
create_all() enforces inventory/allocation relationships, several tests
had to be modified so that they properly accounted for this.
Change-Id: I0bccfee155c871babf507cdd1117b5023d5a1361
The intent is for the resource provider objects to never be used
outside the placement API and for the placement HTTP API to be the
only remote interface to the information represented by the objects.
Therefore there is no need for the versioned objects that provide
the interface between the HTTP API and the database API to be
remotable.
This change removes the remotable decorators and updates tests
accordingly. The objects which have changed have had their versions
updated to provide a marker in their history to indicate that it
happened.
Change-Id: Ic2b431c8ba0af2dea4117687c7ef9477a6655bcf
As of now, in most of the test cases, uuidsentinel is used for
generating a UUID except at some places where uuid4() is used.
In order to maintain consistency, we propose to use uuidsentinel
module for generating UUIDs throughout the test cases.
There are some cases where unique UUIDs are required. For such
cases, generate_uuid() from oslo_utils.uuidutils is used.
Change-Id: Ifaee2f79fc33d189751c4e3f405b579dd8d89784
Adds in the implementation of objects.ResourceClass.create() with checks
that the custom resource class being added doesn't overlap with any
standard (or previously-added custom) resource classes. The
implementation uses a hard-coded number 10000 to mark the start of
custom resource class integer identifiers to make it easy to
differentiate custom resource classes. Note that we do NOT increment the
object version here because nothing as-yet calls the ResourceClass
object.
Also note that this patch adds a required "CUSTOM_" namespace prefix to
all custom resource classes. Followup patches will also place this
constraint into the JSONSchema for POST /resource_classes. The CUSTOM_
namespace is required in order to ensure that custom resource class
names never conflict with future standard resource class additions.
Change-Id: I4532031da19abaf87b1c2e30b5f70ff269c3ffc8
blueprint: custom-resource-classes
The introduction of the _ensure_rc_cache method in lots of places
has caused new database poison errors in test_resource_provider.py.
This changes fixes those issues by mocking the call to _ensure_rc_cache
and the id_from_string/string_from_id methods of the cache object.
Co-Authored-By: Ed Leafe <ed@leafe.com>
Related-Bug: #1568414
Change-Id: Ib8828544772a6e738e43f20591c795d2ef9bf901
Fixes the following warning emitted from test_create_in_db.
SAWarning: Unicode type received non-unicode bind param value
'a7f7228e-1b4d-4a53-a284-4...'.
The ResourceProvider name column expects unicode values.
class ResourceProvider(API_BASE):
...
name = Column(Unicode(200), nullable=True)
Change-Id: I860d82fac4deaf7cc891f42dc47e64e43861a9d9
We added a v1.1 to Usage without a compat routine to go with it. It's not really
a big deal as we're not sending this over RPC anywhere yet that I know of, but
we should have this for the sake of completeness.
Change-Id: Ia50448741b29e1c33e4988a9476418b6ba835983
Originally, the declared names for the resource classes defined in
objects/fields.py were an enum, as the original design assumed that any
future resource classes would be added as a software upgrade release. As
is the convention, this enum was given the name 'ALL'. With the
introduction of custom resource classes that can be added by admins, the
defined classes are no longer an enum, so the name 'ALL' is misleading.
This patch renames it to the more accurate 'STANDARD'.
Change-Id: I251a6faa8c284eb91d190b47108664e67d824425
Blueprint: custom-resource-classes
This patch modifies the fields.ResourceClass field type from an
EnumField to a StringField. This keeps the over-the-wire format of the
field backwards-compatible while allowing us to add non-standardized,
custom resource classes to the new resource_classes database table.
We change all locations of fields.ResourceClass.index() and
fields.ResourceClass.from_index() to use the ResourceClassCache object
added in the previous patch in this series and add some check logic in
Inventory and Allocation object's obj_make_compatible() methods to
ensure backversioned objects requesting or sending with a resource class
string different than the set of strings in the ResourceClass field at
the time of this patch raises a ValueError.
Change-Id: I2c1d4ae277ba25791c426e1c638dca1b1cb207a4
blueprint: custom-resource-classes
This is the object side of creating and deleting allocations in the
placement service.
create_all() checks that the inventory records involved in the
allocations requested do not have their capacities exceeded. If no
inventory capacities are exceeded, allocation records are written to the
database. Afterwards, the resource provider generation for each resource
provider involved in the allocation transaction has its generation
incremented. If another threads has concurrently updated either the
inventory or the usage of resources, this generation increment will
raise ConcurrentUpdateDetected, allowing callers to retry. This patch
does not yet implement this retry, which should be fine for the time
being considering that nothing yet calls POST /allocations.
Partially-Implements: blueprint generic-resource-pools
Co-Authored-By: Jay Pipes <jaypipes@gmail.com>
Co-Authored-By: Ed Leafe <ed@leafe.com>
Change-Id: Ic0bb48dcb1ab33b278f09dee8778fcb7a374caad
If InventoryList.find() was provided with a string of a resource
class that does not exist it would cause an uncaught ValueError.
This would eventually raise up to the Placement API as a 500 in
response, for example, to
'GET /resource_providers/{uuid}/inventories/HOUSE'
NotFound makes sense at both the object and HTTP levels. A unit test
for the object level has been added and a gabbi test for the HTTP
level.
Note: this was discovered while developing some test client code
for the placement API. A simple, but wrong, argument was passed
through the stack and caused a 500.
Change-Id: I0d4066a3f213f726a92d673986b702e08bda4459
Partially-Implements: blueprint generic-resource-pools
An Allocation represents a use of some class of resource from a
particular resource provider, by a consumer. They can be created
and destroyed.
It is also possible get a list of all allocations associated with a
particular resource provider.
This also includes: a small correction to functional tests of Inventory
so that its structure (where resource_class is defined) is aligned
with the Allocation tests.
Co-Authored-By: Dan Smith <dansmith@redhat.com>
Partially-Implements: blueprint resource-providers-allocations
Change-Id: Iaec8a8e318adfd8feae6496ad962bc02d13adebd
Each of these reuses the methods used by set_inventory for
deleting, updating or adding just one Inventory to a
ResourceProvider.
With the addition of these methods, the existing set_inventory
needs a clarifying docstring.
An Inventory.capacity property has been added to validate that
Inventory.total and Inventory.reserved do not conflict. This will
also eventually be used to make comparisons with Usages.
The version of the ResourceProvider object does not require a
version bump, despite the change in object hash, because
ResourceProviders are not yet being used in the wild.
Partially Implements: blueprint generic-resource-pools
Change-Id: I62836faf829b93997a176aba4e0dc3502ae54049
DB call method get_all_by_resource_provider_uuid queries all
Inventories and filters them by provider's uuid from ResourceProvider,
but query list is not valid (contains inventories for all providers),
the correct way to load ResourceProvider is to use query join. Replace
joinedload with contains_eager to avoid redundant joins.
As result last updated provider overwrites all provider's inventories
with wrong data.
Closes-Bug: #1572555
Change-Id: I49fb1bf63400280635c202dea8f870d727a91e81
An Inventory object has some legitimate constraints on its values
that should be reflected in the object. All numeric values that
have a default are non-negative.
The version of the object doesn't need to be updated because
we've not been passing these things around over RPC.
Change-Id: Iadfa041a419e8a7d6f4e3bb62989a08708aa8290
Partialy-Implements: blueprint generic-resource-pools
Needed by following code, this patch adds a simple InventoryList.find()
method that searches for a resource class in an InventoryList and
returns the inventory record matching that resource class, or None if
that resource class is not contained in the InventoryList.
Change-Id: I64757c2115f12788eab46627b0f0a2c8a37433f4
Add 'name' and 'generation' to the ResourceProvider object so that the
humane name and generation counter associated with the provider can be
persisted and used in display.
Change-Id: I5bc19065fdd2bbbeec67908f3feabbd43a492c89
Partially-Implements: blueprint generic-resource-pools
Add ResourceProvider, Inventory and InventoryList objects with
minimal methods for persistence. It is likely the interfaces will
need to be expanded as these things are actually used.
An inventory can be created or updated or a list of inventories can
be retrieved by resource provider uuid.
A resource provider can be created and retrieved by uuid.
Inventory shares some code with a forthcoming Allocation object that
used to be in this patch will now come later. That sharing is via a
_HasAResoureProvider superclass.
Tests are mixed between unit and functional. The functional tests
explore the arc of an expected task.
Co-Authored-By: Dan Smith <dansmith@redhat.com>
Partially-Implements: blueprint resource-providers
Change-Id: I578eebf04c3b5d881aa7be7b72691515f2cf6758
Chris Dent