The functional testenv doesn't work with python 3.x on our codebase.
If someone is on a platform that defaults to python => python3,
functional tests will fail for them.
Closes-Bug: #1632521
Change-Id: I7bf6653f55c10d0a4f75054e519edf7da19c5c09
We will store custom resource classes in the new resource_classes table.
These custom resource classes represent non-standardized resource
classes. Followup patches add the plumbing to handle existing
standardized classes currently using the fields.ResourceClass field type
and to perform CRUD operations against a /resource-classes REST API
endpoint.
Change-Id: I60ea0dcb392c1b82fead4b859fc7ed6b32d4bda0
blueprint: custom-resource-classes
Add the following notifications when swapping volumes.
* 'instance.volume_swap.start'
* 'instance.volume_swap.end'
A subsequent patch will add 'instance.volume_swap.error'.
Change-Id: Ic4d9d25bdc611221157e4663817e918b8d667ce9
Implements: blueprint add-swap-volume-notifications
String interpolation should be delayed to be handled
by the logging code, rather than being done
at the point of the logging call.
So add the following hacking rule for it.
- [N354] String interpolation should be delayed at logging calls.
See the oslo i18n guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
Change-Id: Ief6d3ee3539c0857098fffdb7acfeec3e0fed6eb
Closes-Bug: #1596829
Upgrade to gabbi 1.26.1 to use the new inner_fixtures feature to
capture log and stdout/stderr per individual test request. The
existing nova fixtures are used for the capture.
Depends-On: Ic13dc14f62334aefbcced93872ec564cab157898
Change-Id: Ic6f5a50df37b4680a60c4aa94f7587aec232c367
The initial bug was that the initial 'Starting' log provided by
requestlog had a different request id from the rest of the log
messages for the same request. The initial assumption was that this
was because a request id was not initially available, causing one
to be generated for the first log entry that later was replaced
by the request id middleware.
In the process of debugging that it became clear that the id was
in fact the request id of the previous request because the context
was being reused under the covers in oslo_log and olso_context.
Therefore the auth, context and request id middlewares are now
changed to be active in the middleware stack before the request log
middleware. The unfortunate side effect of this is that the Starting
message and final request logging is no longer actually bounding the
full request: it misses three critical middlewares.
Change-Id: Ifa412973037193e4e67a0c9d2c71c7a4847980a9
Closes-Bug: #1626493
The cover job runs the unit tests and having stale
pycs can skew those results, so remove the pyc files
before running the tests with --coverage.
Change-Id: I7393d2df36e715dbf53ba9ae6a077bdc8e79b5a5
mod-wsgi checks that response header values are what's described
as "native strings". This means whatever `str` is in either
python 2 or 3, but never `unicode`. When they are not mod-wsgi
will 500. For the most part this is taken care of by webob, but in
the case of the 405 handling, the webob response is not being
fully massaged.
mod-wsgi is doing this because it supposed to. Python WSGI server
gateways have different expectations of headers depending on whether
the Python is 2 or 3. See
https://www.python.org/dev/peps/pep-3333/#a-note-on-string-types
In addition to the unit test, the gabbi tests are now using a
version of wsgi-intercept that will raise a TypeError when the
application response headers are not using the correct form. This
check needs to be done in wsgi-intercept rather than the gabbi tests
because both wsgi-intercept and the http client makes requests
transform the headers for their own purposes.
This fix ensures that instead of a 500 the correct 405 response
happens.
Closes-Bug: #1626496
Depends-On: I3b8aabda929fe39b60e645abb6fabb9769554829
Change-Id: Ifa436e11e79adc2e159b4c5e7d3623d9a792b5f7
This is something I expect has been very broken for a long time. We
have rows in tables such as instance_extra, instance_faults, etc that
pertain to a single instance, and thus have a foreign key on their
instance_uuid column that points to the instance. If any of those
records exist, an instance can not be archived out of the main
instances table.
The archive routine currently "handles" this by skipping over said
instances, and eventually iterating over all the tables to pull out
any records that point to that instance, thus freeing up the instance
itself for archival. The problem is, this only happens if those extra
records are actually marked as deleted themselves. If we fail during
a cleanup routine and leave some of them not marked as deleted, but
where the instance they reference *is* marked as deleted, we will
never archive them.
This patch adds another phase of the archival process for any table
that has an "instance_uuid" column, which attempts to archive records
that point to these deleted instances. With this, using a very large
real world sample database, I was able to archive my way down to
zero deleted, un-archivable instances (from north of 100k).
Closes-Bug: #1622545
Change-Id: I77255c77780f0c2b99d59a9c20adecc85335bb18
The DeleteFromSelect function was added to sqla.utils, which is mostly
the home of 2 shadow table functions that need to import api.py to get
constants related to shadow tables. We now exclusively use that
function in api.py for archiving code. That causes some oddities
around module import.
This moves DeleteFromSelect so we can get rid of these odd late
imports.
Change-Id: I59c3444c2258f59a09a9c885bd9490055e278998
Removed context object while logging as Nova uses oslo.context's
RequestContext which means the context object is in scope when doing
logging. Added hack to notify, in case if someone uses it in logging
statements in future.
Change-Id: I5aaa869f2e6155964827e659d18e2bcaad9d866b
Closes-Bug:#1500896
The only entry in rpc.py would be better living in notifications.py.
At that point we can just delete rpc.py.
Blueprint centralize-config-options-ocata
Change-Id: Id4d41339a5f8e1102baa4705fc93a99c151d3ac5
When mounted under a prefix (such as /placement) the service was
only returning the home document at /placement/ not /placement. In
the context of having a prefix, we'd generally like the latter to
work and for '/' to work when there is no prefix. This allows both.
Note that this doesn't make /placement/resource_providers/ work, and
we don't want that.
Change-Id: I0ac92bf9982227d5f4915175182e5230aeb039b4
Closes-Bug: #1626490
Prior to this change, a 404 caused by a not possible route being
requested (such as /placement/hello) would result in a proper 404
response but also a log message about an uncaught exception. This
made it appear that a 404 response is unexpected and something that
needs exceptional attention. It doesn't. This change makes sure
that 404s propagate up the stack in a clean way and are logged only
by the existing INFO log used for all requests.
Change-Id: I21f9411bd5154eddc582d5f38891be747de874b3
Closes-Bug: #1626489
As of now, UUID is being generated using either uuid.uuid4()
or uuidutils.generate_uuid(). In order to maintain consistency,
we propose to use uuidutils.generate_uuid() from oslo_utils.
Change-Id: I69d4b979fc0e37bc351f9b5516dae899e7e7dba0
