cfc167eadf
Currently we have a pecan feature enabled that strips extensions from the end of the URL and treat it like requested content type. E.g. /v1/nodes.json is treated as /v1/nodes with requested content type Application/Json. However, this prevents certain node names: e.g. /v1/nodes/small.1 is treated like /v1/nodes/small with content type of a man page. It does not make any sense for ironic API, as we only support Application/Json content type (and .json suffix). This change disabled this pecan feature. To keep backward compability a new middleware stips the .json prefix and saves a flag in the environment about its presence. API accepting names try to find their resource first without, then with .json suffix. The following endpoints are special-cased to support names with .json: * Node GET, PATCH and DELETE * Ramdisk heartbeat * Port group GET, PATCH and DELETE VIF API is not updated, so VIF IDs still cannot have .json suffix. Change-Id: I789ecfeac9b64a9c4105a20619f7bf5dfc133189 Closes-Bug: #1643995
20 lines
864 B
YAML
20 lines
864 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Nodes and port groups with names ending with known file extensions are now
|
|
correctly handled by the API. See `bug 1643995
|
|
<https://bugs.launchpad.net/bugs/1643995>`_ for more details.
|
|
issues:
|
|
- |
|
|
If you have two nodes or port groups with names that only differ in
|
|
a ``.json`` suffix (for example, ``test`` and ``test.json``) you won't be
|
|
able to get, update or delete the one with the suffix via the
|
|
``/v1/nodes/<node>`` endpoint (``/v1/portgroups/<portgroup>`` for port
|
|
groups). Similarly, the ``/v1/heartbeat/<node>`` endpoint won't work
|
|
for the node with the suffix.
|
|
|
|
To work around it, add one more ``.json`` suffix (for example, use
|
|
``/v1/nodes/test`` for node ``test`` and ``/v1/nodes/test.json.json``
|
|
for ``test.json``). This issue will be addressed in one of the future
|
|
API revisions.
|