This patch introduces a new API microversion which will be
used to alter the responses of ``GET /servers``, ``GET /servers/detail``,
``GET /servers/{server_id}`` and ``GET /os-services`` when a cell is
down to return minimal constructs with missing keys.
Implements blueprint handling-down-cell
Change-Id: Id9f12532897912b39093f63e9286540d9029edeb
This patch introduces a new microversion to identify services by uuid
instead of id, to ensure uniqueness across cells. GET /os-services
returns uuid in the id field, and uuid must be provided to delete a
service with DELETE /os-services/{service_uuid}.
The old PUT /os-services/* APIs are now capped and replaced
with a new PUT /os-services/{service_uuid} which takes a uuid path
parameter to uniquely identify the service to update. It also restricts
updates to nova-compute services only, since disabling or forcing-down
a non-compute service like nova-scheduler doesn't make sense as it
doesn't do anything.
The new update() method in this microversion also avoids trying to
re-use the existing private action methods like _enable and _disable
since those are predicated on looking up the service by host/binary,
are confusing to follow for code flow, and just don't really make sense
with a pure PUT resource update method.
Part of blueprint service-hyper-uuid-in-api
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Change-Id: I45494a4df7ee4454edb3ef8e7c5817d8c4e9e5ad
This patch move the all v2.1 api sample tests under
'functional/api_sample_tests'. Also move sample files under
'doc/api-samples'.
Co-Authored-By: Ed Leafe <ed@leafe.com>
Co-Authored-By: Alex Xu <hejie.xu@intel.com>
Partial-Bug: #1462901
Change-Id: I2b924f2ad7687a23a018a9b658e8acd9e04d7963
Currently v2 and v2.1 have separate functional tests and their
corresponding sample files. As v2 and v2.1 are supposed to be identical,
there is overhead to maintain two set of functional tests and sample files.
We can have one set of tests which can run for both v2 and v2.1.
This commit merges services functional tests.
In V2 services API has following extensions
- os-services
- os-extended-services-delete
- os-extended-services
In V2.1 above extensions have been merged together in services plugins
Change-Id: I498e80aef9c05b125d396f40fcb0e6ae4bef8da6
In I5a580fc323c3809790b4a68a9f8f8129ecdc2cf0 we switched off XML support. In
this review we entirely remove all the testcases and supporting files.
Change-Id: I83827d438753fd3899053dd6e09bc77c997c7406
If a service is enabled, the "disabled_reason" field in response
for /v2/.{tenant_id}./os-services/detail is null, however, currently
it's specified as "" in the doc, thus may be confusing to users.
This patch change the template and doc, it should not cause issue to
existing applications.
Change-Id: Ia71ec4c97a355bcc1a7b63e6107db77f80a5d843
Close-bug: 1328382
datetime objects are serialized into xml using simply str() and this
is a slightly different format from ISO8601 in that the date isn't
separated from the time using 'T'.
(However, note that the iso8601 library happily accepts this format)
Add a specific regexp for this format so we can test for it in the
places we know it is used. This also means we can remove the generic
%(timestamp)s regexp.
Note that unlike the isotime and strtime formats, whether this format
includes timezone or microsecond information depends on whether the
datetime object had those fields set. The isotime format always
includes a timezone but not microseconds, whereas the strtime format
never includes a timezone but always includes microseconds.
There are a small number of examples where this format is used in JSON
too - e.g. the instance usage audit log extension pre-serializes its
timestamps by doing:
return dict(period_beginning=str(begin),
period_ending=str(end),
Using a name like 'xmltime' for the timestamp format used in cases
like this actually makes sense - it highlights that the format used
in this case is a weird mistake.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: I70f839ac17273ed10078b833aeba308bd5e994e1
Implements blueprint record-reason-for-disabling-service
We added a field to the service table to log a reason when a service has
been disabled.
We added a new API extension called os-extended-services. The new extension
will extend the os-services extension adding:
- A method for disabling a service and specify a reason for that.
PUT /v2/{tenant_id}/os-services/disable-log-reason
When the os-extended-extension is loaded the call:
GET /V2/{tenant_id}/os-services
will return the list of services with reason information it that exists.
DocImpact
Change-Id: I87a4affc45160796ff11c7b03e591e6aba73d62a
Partially implements blueprint nova-api-samples
fixes bug 1130609
The XML serializer for the update method in the os-services API extensions was
not serializing the "updated_at" field because of a typo in the code.
In this change we added api_samples for the XML output.
Change-Id: I9fff0677e9bad650b19e559b3ed6e9bc0ffe8c3c
Updates the os-services API extension so that it is consistent
internally (index and update return similar formats), and so
that it works with the recent novaclient code which sends
the following request body format:
{"binary": "nova-cert", "host": "nova1"}
Also, updates the response body format of the update call so that it
wraps things in an extra service dict which should make novaclient
happier here as well (and is consistent with other extensions too).
Fixes LP Bug #1147746.
Change-Id: I932160d64fdd3aaeb2ed90a092ecc7a36dcc9665
Surya Seetharaman