This finalizes the removal of the placement code from nova.
This change primarily removes code and makes fixes to cmd,
test and migration tooling to adapt to the removal.
Placement tests and documention were already removed in
early patches.
A database migration that calls
consumer_obj.create_incomplete_consumers in nova-manage has been
removed.
A functional test which confirms the default incomplete
consumer user and project id has been changes so its its use of
conf.placement.incomplete_* (now removed) is replaced with a
constant. The placement server, running in the functional
test, provides its own config.
placement-related configuration is updated to only register those
opts which are relevant on the nova side. This mostly means
ksa-related opts. placement-database configuration is removed
from nova/conf/database.
tox.ini is updated to remove the group_regex required by the
placement gabbi tests. This should probably have gone when the
placement functional tests went, but was overlooked.
A release note is added which describes that this is cleanup,
the main action already happened, but points people to the
nova to placement upgrade instructions in case they haven't
done it yet.
Change-Id: I4181f39dea7eb10b84e6f5057938767b3e422aff
This adds policy rules or the various /resource_classes*
routes with the default being backward compatible with
existing deployments (requires role:admin).
The "non admin forbidden non json" gabbit had to be changed
because the policy check moved so the test would fail with a
406 response instead of 403.
Part of blueprint granular-placement-policy
Change-Id: I90ef62e8e7b9e75830ac60e0c5c7e92845ab4afe
This change moves the exceptions raised within the placement service
into the nova.api.openstack.placement package. This is part of the
process of unifying all placement code into one subdirectory so that
a future lift and shift is easier and cleaner.
This is mostly a straightforward change of imports and a moving of
existing exceptions in the placements handlers and objects with a few
caveats:
* Dealing with nova/db/sqlalchemy/resource_class_cache.py has not
yet been accomplished, so it remains where it is and imports
exceptions from the placement hierarchy. A TODO indicating some of the
options is left for future work.
* Exceptions with the name ResourceProviderInUse and InventoryInUse are
used on both sides of the nova/placement interaction. This is
noted with comments in both nova/exception.py and
placement/exception.py.
* test_report_client.py has had a TODO added to make it clear that the
exceptions it uses are nova-side, and perhaps the test file should be
moved.
* The base class of the original exceptions, NoveException, does a bit
more than is required on the placement side so a new private class
_BaseException is created which removes support for handling 'code'.
This is not required because all exceptions in placement are supposed
to be manually caught in handlers and explicitly transformed into http
exceptions.
blueprint placement-extract
Change-Id: I2b94945a0963d6a61af931505b69afe2d4733759
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
In compute APIs, they have their schemas in the
independent directory (nova/api/openstack/compute/schemas).
Placement APIs should be like that as well.
This patch separates API schemas to an independent directory
(nova/api/openstack/placement/schemas)
from nova/api/openstack/placement/handlers/resource_class.py.
Subsequent patches will move schemas of other handlers.
Change-Id: I61bfc96953d1158d3204d3f578a5255c18af2d6e
In relevant requests to the placement API add last-modified
and cache-control headers.
According 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 change adds a microversion 1.15 which adds the headers to GET
requests and some PUT or POST requests.
Despite what it says 'no-cache' means "check to see if the version you
have is still valid as far as the server is concerned". Since our server
doesn't currently validate conditional requests and will always return an
entity, it ends up meaning "don't cache" (which is what we want).
The main steps in the patch are:
* To both the get single entity and get collection handlers add
response.cache_control = 'no-cache'
* For single entity add response.last_modified = obj.updated_at or
obj.created_at
* For collections, discover the max modified time when traversing the
list of objects to create the serialized JSON output. In most of
those loops an optimization is done where we only check for
last-modified information if we have a high enough microversion such
that the information will be used. This is not done when listing
inventories because the expectation is that no single resource
provider will ever have a huge number of inventory records.
* Both of the prior steps are assisted by a new util method:
pick_last_modfied.
Where a time cannot be determined the current time is used.
In typical placement framework fashion this has been done in a very
explicit way, as it makes what the handler is doing very visible, even
though it results in a bit of boilerplate.
For those requests that are created from multiple objects or by doing
calculations, such as usages and aggregate associations, the current time
is used.
The handler for PUT /traits is modified a bit more extensively than some
of the others: This is because the method can either create or validate
the existence of the trait. In the case where the trait already exists,
we need to get it from the DB to get its created_at time. We only do
this if the microversion is high enough (at least 1.15) to warrant
needing the info.
Because these changes add new headers (even though they don't do
anything) a new microversion, 1.15, is added.
Partial-Bug: #1632852
Partially-Implements: bp placement-cache-headers
Change-Id: I727d4c77aaa31f0ef31c8af22c2d46cad8ab8b8e
when delete a standard resource class, we can meet with error:
Unable to delete resource class VCPU: Unable to delete resource class VCPU
which is duplicate.
Trivial Fix
Change-Id: Ib5a4bbb75affbb44eb28719b135a73903ce1a3de
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
Unregister the ResourceClassList 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 ResourceClassList class
* where objects.ResourceClassList is used, point directly to the
nova.objects.resource_provider package instead
Partially-Implements: bp placement-deregister-objects
Change-Id: I109cceb08050b2714c2a2409bf4674f718ab29d6
In a microversion 1.7 change PUT /resource_classes/{name} so that
creation and existence validation of a custom resource class can
happen in a single request and prevent the previous behavior of
being able to update a single resource class to a new name, which is
not desirable.
The previous update_resource_class is still in place to support
microversion 1.2-1.6.
The original resource-classs.yaml sets the default microversion
header to 'latest' so for those existing tests that are using the
old style of PUT, a '1.6' header has been added. New files for
version 1.6 (to add a "no 1.7 behavior here" test) and 1.7 (testing
the new PUT behavior and explicitly verifying POST to create is
still around) are added.
Change-Id: I95f62ab2cb1ab76d18fb52b93f87ed28e4e7b5f3
Implements: bp placement-put-resource-class
When microversioned request handling was added to placement some
comparisons were added that treat the microversions as floats. This
will break as soon as the right hand side of the version chnages
from one digit to two. A float of 1.1 and 1.10 is the same. A
version string of '1.1' and '1.10' is not.
This patch changes the internals of version handling to always use
Version objects which represent the versions using a name tuple
(major=1, minor=10). It also changes the externals to expect versions
as strings ('1.10'). Where floats were present before, these have
been changed to strings. Where tuples have been accepted, these are
still accepted, but strings are as well.
This is an internal only change, users shouldn't notice any
difference as their versions (in the openstack-api-version header)
were always strings and we haven't made it to version 1.10, sorry
'1.10', yet.
If developers try to version_handler with something other than a
version string, test runs will fail very early (at import time).
Change-Id: Ic2b655ac4c75c6104eddecd174f193413a0764d2
Closes-Bug: #1675143
Change decorator for resource based actions in resource_class
handler to wsgi_wrapper.PlacementWsgify
This is a newly introduced wrapper class around webob.dec.wsgify
to set json formatter in case of webob exceptions.
Change-Id: Ic330d23b2eda3b3f299291b9cdc4489d02481786
Partial-Bug: #1635182
When create resource class using placement API, and at
the DB layer, we have a retry logic for 100 loop, and
error will raise when the retry limit exceed, currently
a log about limit exceed is generated but a
ResourceClassExists Error is raised, which is a little
bit weird and might confuse the users.
We'd better add a particular Exception for this kind of
scenario and it could be used in other places also.
Co-Authored-By: huangtianhua@huawei.com
Closes-Bug: #1658868
Change-Id: I89156be82ad520bdeacb12b31b44e7170b77ce3f
When update resource class with existed one's name,
the exception message was formatted by the updated resource
class's name, rather than the required existed one's name.
This patch formats the message with existed one's name, and
changing tests to add the right name.
Change-Id: I78ae8d872748de243d74b9954ce634fccf5e7310
Closes-Bug: #1663163
Get nova.boot_server, nova.attach_volume, nova.detach_volume and
nova.delete_server working. Please see the following cinder review
for the experiment (see gate-rally-dsvm-py35-cinder-nv):
Id78b136ad15ac77717711ebcbb671c2f1dd3a10c
nova/api/openstack/placement/handlers:
* make sure we convert to bytes before we set the response.body
nova/tests/functional/db/api/test_migrations.py:
* range is an iterator and must be converted to a list
nova/tests/unit/virt/libvirt/test_driver.py:
nova/tests/unit/virt/libvirt/test_fakelibvirt.py:
nova/virt/libvirt/config.py:
nova/virt/libvirt/guest.py:
nova/virt/libvirt/host.py:
* libvirt API expects strings, some of the code paths ended up
being bytes, so convert them to strings before calling libvirt
Finally, eliminated the tests that now started to pass from
tests-functional-py3.txt
Change-Id: Ib721442e9d83a3b9a7fe597f3886430449a9e684
APIs listed below are returning 500 error if you pass name more than
255 characters.
1. create resource_classes
2. update resource_classes
Added maxLength check in schema to ensure name should not be more than
255 characters.
Closes-Bug: #1648314
Change-Id: I4ae54f3061fe43d87a656088db1d2ae454eb8237
This patch adds support for a REST API for CRUD operations on custom
resource classes:
GET /resource_classes: return all resource classes
POST /resource_classes: create a new custom resource class
PUT /resource_classes/{name}: update name of custom resource class
DELETE /resource_classes/{name}: deletes a custom resource class
GET /resource_classes/{name}: get a single resource class
Change-Id: I99e7bcfe27938e5e4d50ac3005690ac1255d4c5e
blueprint: custom-resource-classes
Chris Dent