Commit Graph

9 Commits

Author SHA1 Message Date
Chris Dent 787bb33606 Use external placement in functional tests
Adjust the fixtures used by the functional tests so they
use placement database and web fixtures defined by placement
code. To avoid making redundant changes, the solely placement-
related unit and functional tests are removed, but the placement
code itself is not (yet).

openstack-placement is required by the functional tests. It is not
added to test-requirements as we do not want unit tests to depend
on placement in any way, and we enforce this by not having placement
in the test env.

The concept of tox-siblings is used to ensure that the
placement requirement will be satisfied correctly if there is a
depends-on. To make this happen, the functional jobs defined in
.zuul.yaml are updated to require openstack/placement.

tox.ini has to be updated to use a envdir that is the same
name as job. Otherwise the tox siblings role in ansible cannot work.

The handling of the placement fixtures is moved out of nova/test.py
into the functional tests that actually use it because we do not
want unit tests (which get the base test class out of test.py) to
have anything to do with placement. This requires adjusting some
test files to use absolute import.

Similarly, a test of the comparison function for the api samples tests
is moved into functional, because it depends on placement functionality,

TestUpgradeCheckResourceProviders in unit.cmd.test_status is moved into
a new test file: nova/tests/functional/test_nova_status.py. This is done
because it requires the PlacementFixture, which is only available to
functional tests. A MonkeyPatch is required in the test to make sure that
the right context managers are used at the right time in the command
itself (otherwise some tables do no exist). In the test itself, to avoid
speaking directly to the placement database, which would require
manipulating the RequestContext objects, resource providers are now
created over the API.

Co-Authored-By: Balazs Gibizer <balazs.gibizer@ericsson.com>
Change-Id: Idaed39629095f86d24a54334c699a26c218c6593
2018-12-12 18:46:49 +00:00
Chris Dent dd13c2784b Add placement.concurrent_udpate to generation pre-checks
We have two kinds of generation conflicts that happen (for both
resource providers and consumers). In
I5a164a0ee298846231113ad7b62b82a3e8f1f409 error codes are added for
conflicts that happen when incrementing the generation in the database.s

In this change the codes are added for those situations where in code we
are checking an incoming generation against the stored generation.

Since there are incoming genearations in this case, we can add tests
so this does, via gabbi.

Change-Id: I5ed005068c1c19194ed67556376604ae90727412
2018-07-11 15:56:12 +01:00
Eric Fried 388db7e6e2 placement: Return new provider from POST /rps
To facilitate opaqueness of resource provider generation internals, we
need to return the (initial) generation when a provider is created. For
consistency with other APIs, we will do this by returning the entire
resource provider record (which includes the generation) from POST
/resource_providers.

Change-Id: I8624e194fe0173531c5aa2119c903e3c68b8c6cd
blueprint: generation-from-create-provider
2018-03-14 17:08:55 -05:00
Eric Fried 3216f078d4 placement: generation in provider aggregate APIs
Placement API microversion 1.19 enhances the payloads for the `GET
/resource_providers/{uuid}/aggregates` response and the `PUT
/resource_providers/{uuid}/aggregates` request and response to be
identical, and to include the ``resource_provider_generation``. As with
other generation-aware APIs, if the ``resource_provider_generation``
specified in the `PUT` request does not match the generation known by
the server, a 409 Conflict error is returned.

Change-Id: I86416e35da1798cdf039b42c9ed7629f0f9c75fc
blueprint: placement-aggregate-generation
2018-03-14 17:08:52 -05:00
Zuul f6d4c46c33 Merge "Add more functional test for placement.aggregates" 2018-03-07 00:55:36 +00:00
jichenjc a6d456f954 Add more functional test for placement.aggregates
Add more test cases for placement.aggregates to cover some edge case.

blueprint placement-test-enhancement

Change-Id: Ia18de50f3265b358e64523229140ce9a6e70dbbb
2018-03-06 21:46:27 +00:00
Chris Dent 83030804cc [placement] Add cache headers to placement api requests
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
2017-12-12 15:51:58 +00:00
Pushkar Umaranikar 9923c1570b Placement api: set custom json_error_formatter in aggregate and usage
Change decorator for resource based actions in aggreagate and usage
handlers 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: I44ab22befad347b23ddb8d93d840ba594b988ce3
Partial-Bug: #1635182
2017-02-13 18:34:10 +00:00
Chris Dent 44ca84a7e1 Implement get and set aggregates in the placement API
/resource_providers/{uuid}/aggregates
GET for a list of aggregate uuids associated with this resource
    provider
PUT to set the list of aggregate uuids associated with this this
    provider

The API requests map directly to set_ and get_ aggregates on the
ResourceProvider object.

This is implemented as placement API microversion 1.1. To make that
easier a raise_404_if_not_version helper method is added to the
microversion module.

The new rest_api_version_history doc is updated to reflect this
new version.

Change-Id: I514c15c7d387cf25bf7986d07baccf0e7a785f46
Partially-Implements: blueprint generic-resource-pools-ocata
2016-11-17 17:32:13 +00:00