quantum remote-router-interface should not return a 'null' body

Bug #1173284 reported by Stephen Ma on 2013-04-26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Armando Migliaccio

Bug Description

According to the Quantum API doc regarding the remove_router_interface API, the Normal Response code is 200 and the request "does not return a response body."

However, a successful execute of the "quantum router-interface-delete <router> <subnet>" command results in a response that have the string 'null' in it.

stack@ubuntu-2:/tmp$ QUANTUMCLIENT_DEBUG=1 quantum router-interface-delete t1-router t1-sub
REQ: curl -i -X PUT -H "User-Agent: python-quantumclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: MIILhAYJKoZIhvcNAQcCoIILdTCCC3ECAQExCTAHBgUrDgMCGjCCCl0GCSqGSIb3DQEHAaCCCk4EggpKeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0yNlQxNjozNjoxNi4yNzEwODIiLCAiZXhwaXJlcyI6ICIyMDEzLTA0LTI3VDE2OjM2OjE2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogbnVsbCwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiNTAyNTZkYTRkMDFhNDY2ODgyMTdhYzY4YjY0YTU5MTciLCAibmFtZSI6ICJ0ZW5hbnQtMSJ9fSwgInNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEwLjEzMy4xMC4yMTk6ODc3NC92Mi81MDI1NmRhNGQwMWE0NjY4ODIxN2FjNjhiNjRhNTkxNyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMC4xMzMuMTAuMjE5Ojg3NzQvdjIvNTAyNTZkYTRkMDFhNDY2ODgyMTdhYzY4YjY0YTU5MTciLCAiaWQiOiAiMGIyYzNmNWZkNmQyNDVmYzk0MjAyZmE4MWFhOTA3NzQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMC4xMzMuMTAuMjE5Ojg3NzQvdjIvNTAyNTZkYTRkMDFhNDY2ODgyMTdhYzY4YjY0YTU5MTcifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiY29tcHV0ZSIsICJuYW1lIjogIm5vdmEifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTo5Njk2LyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMC4xMzMuMTAuMjE5Ojk2OTYvIiwgImlkIjogIjEyZjRkMTYzMDVlOTQ5ZjFhMzQxMDQ5MjM3YWEwZWJlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTo5Njk2LyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJuZXR3b3JrIiwgIm5hbWUiOiAicXVhbnR1bSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMzMuMTAuMjE5OjMzMzMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTozMzMzIiwgImlkIjogIjZkMmM0YTM3NzQ2NjRjZDA5OWNiNGVkMjVhNWE4YmFjIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTo5MjkyIiwgInJlZ2lvbiI6ICJSZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEwLjEzMy4xMC4yMTk6OTI5MiIsICJpZCI6ICIzMmM2ZmYxMmFmMGY0ZjQ5ODkxODVkZjdhYTMyYTk0MSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEwLjEzMy4xMC4yMTk6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMzMuMTAuMjE5Ojg3NzYvdjEvNTAyNTZkYTRkMDFhNDY2ODgyMTdhYzY4YjY0YTU5MTciLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTo4Nzc2L3YxLzUwMjU2ZGE0ZDAxYTQ2Njg4MjE3YWM2OGI2NGE1OTE3IiwgImlkIjogIjI2MWNiZDZjOTQwZTQyODVhNDQ3MzdiY2FmMTNhZDI5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTo4Nzc2L3YxLzUwMjU2ZGE0ZDAxYTQ2Njg4MjE3YWM2OGI2NGE1OTE3In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMzMuMTAuMjE5Ojg3NzMvc2VydmljZXMvQWRtaW4iLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTo4NzczL3NlcnZpY2VzL0Nsb3VkIiwgImlkIjogIjEyMTFlZGRiOWZjYzQwNzliNzBjZjEzODkwOTYxMGYyIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMzMuMTAuMjE5OjM1MzU3L3YyLjAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTMzLjEwLjIxOTo1MDAwL3YyLjAiLCAiaWQiOiAiODdkOTUwYjlhMjdhNDVlZGI2N2YxMTEwZDdkMjZlMGEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMC4xMzMuMTAuMjE5OjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAidXNlci0xIiwgInJvbGVzX2xpbmtzIjogW10sICJpZCI6ICJlMDhkNmExYmVhZDY0YmIyYmM4ZjkxNDNiZTVjMzA2NiIsICJyb2xlcyI6IFt7Im5hbWUiOiAiX21lbWJlcl8ifV0sICJuYW1lIjogInVzZXItMSJ9LCAibWV0YWRhdGEiOiB7ImlzX2FkbWluIjogMCwgInJvbGVzIjogWyI5ZmUyZmY5ZWU0Mzg0YjE4OTRhOTA4NzhkM2U5MmJhYiJdfX19MYH-MIH8AgEBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVVuc2V0MQ4wDAYDVQQHEwVVbnNldDEOMAwGA1UEChMFVW5zZXQxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbQIBATAHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASBgFrti+qiwY25JAYyB98DqE1b0LLTvheQRnQr7wk7X38VRALTed5vVsf+HfvRUK-ymK+F6+c2PqSMaxZpIrB029JUQQ0yDoRCw0kNsxZJyPBNNsMTyUbV9dYt-pPOHnDnq3JRjvCNmd1lZBQedHZJtmIkyiCP2fdtYq8O8Ynzm6ju" -d '{"subnet_id": "f5259d72-f534-46d1-a9a7-319dcb45d837"}'

RESP:{'date': 'Fri, 26 Apr 2013 16:36:16 GMT', 'status': '200', 'content-length': '4', 'content-type': 'application/json; charset=UTF-8'} null

Removed interface from router t1-router

Note: before executing the command: both router "t1-router" and the subnet "t1-sub" exists.
Should the normal response code for remove_router_interface be 204?

Tags: api Edit Tag help
Changed in quantum:
status: New → Incomplete
status: Incomplete → New

Sorry, accidental click :)

I confirm that null is returned, when in fact no response body is more appropriate.

The API should indeed return 204 and even though this would break the current API contract, this sounds like a valid bug.

If this bug is accepted, I would suggest to raise another bug for updating the doc.

Changed in quantum:
status: New → Confirmed
tags: added: api
Stephen Ma (stephen-ma) wrote :

Sorry, typo in the title. It should be

"Response of quantum remove-router-interface has 'null'"

Changed in quantum:
assignee: nobody → Salvatore Orlando (salvatore-orlando)
importance: Undecided → Medium
milestone: none → havana-1
assignee: Salvatore Orlando (salvatore-orlando) → Armando Migliaccio (armando-migliaccio)

By a quick scan to the API, it looks like nearly all delete/remove operations return 204 and no body. The exceptions I could find is just remote-router-interface even floatingip-delete, which by mistake is documented as returning 200 (https://bugs.launchpad.net/openstack-api-site/+bug/1174477), actually returns 204 and no body.

So I am proposing to align this operation to the other 'delete' ones, where no response body and 204 response code are returned. To this aim, I am changing the title of this bug.

summary: - Response of quantum remote-router-interface has 'null'
+ Response of quantum remote-router-interface should return 204 and no
+ response body
summary: - Response of quantum remote-router-interface should return 204 and no
- response body
+ quantum remote-router-interface should return 204 and no response body

By the looks of things, it seems that the response status cannot be changed without causing quite a number of side effects to the API.

Response statuses are hard-coded for all the 'create' (201) and 'delete' (204) methods and by _design_ all the others return 200 on success. Even if a method's return value is None, this is going to be serialized into 'null', with no means to dictate the response code if not by the 'action' value defined in api/v2/resource.py.

If a 204 response code on null body would be enforced, this might have unpredictable consequences to other API calls that also return None as a result.

Unless the API code is refactored to be more flexible, I regret to say that this bug is a no-goer.

Opinions welcome.

Stephen Ma (stephen-ma) wrote :

The reason for response status being 201 for create and 204 for delete is by the action_status dictionary in resource.py. The action for a "quantum router_interface_delete" command is "remove_router_interface". So adding a new definition to the action_status dictionary will allow router_interface_action to have a status of 204.

This is what I mean:

 git diff origin/master quantum/api/v2/resource.py
diff --git a/quantum/api/v2/resource.py b/quantum/api/v2/resource.py
index 97fc8a8..c9931b9 100644
--- a/quantum/api/v2/resource.py
+++ b/quantum/api/v2/resource.py
@@ -46,7 +46,7 @@ def Resource(controller, faults=None, deserializers=None, serializers=None):
                            'application/json': wsgi.JSONDictSerializer()}
     format_types = {'xml': 'application/xml',
                     'json': 'application/json'}
- action_status = dict(create=201, delete=204)
+ action_status = dict(create=201, delete=204, remove_router_interface=204)

     default_deserializers.update(deserializers or {})
     default_serializers.update(serializers or {})

Steve, thanks for pointing this out, I totally get what you're saying.

However I fear that what you're proposing would raise quite a few eyebrows.

Mark McClain (markmcclain) wrote :

The proposed patch is relatively small, but it is adding logic about an extension into the core. For consistency, I think that we should return a value in the interim. There's a longer term project to update the WSGI handling within Quantum and we can revisit the return value as part of that process.

Thanks Mark, I'll act accordingly.


summary: - quantum remote-router-interface should return 204 and no response body
+ quantum remote-router-interface should not return a 'null' body

As a stop-gap solution we'll keep the 200 response status and change the response body so that it does not contain the string 'null', but something meaningful like the router id or the list of interfaces that are still attached.

Documentation bug:


will be used to update the fact that the response body is not empty.

I will also file another bug to track the change of the response status to 204, and the response body to no-content (which will come with a bump of the API version); this will be done in the context of the WSGI refactoring that Mark mentioned above.

Fix proposed to branch: master
Review: https://review.openstack.org/27868

Changed in quantum:
status: Confirmed → In Progress

Reviewed: https://review.openstack.org/27868
Committed: http://github.com/openstack/quantum/commit/2516c136549195a92a20aa6570e27af5dfbef28a
Submitter: Jenkins
Branch: master

commit 2516c136549195a92a20aa6570e27af5dfbef28a
Author: armando-migliaccio <email address hidden>
Date: Tue Apr 30 16:19:04 2013 -0700

    Fix 'null' response on router-interface-remove operation

    To avoid a 'null' response body, the delete operation returns a response
    that is consistent with its add counterpart, i.e. we return the router
    id with details about the interface being affected by the operation, as
    well as the tenant id.

    A unit test is added to ensure that the right body is returned and minor
    adjustments have been made to the plugins affected by the change.

    Long-term, a delete operation should really return 204 w/o a body, but
    this requires some major rework of the WSGI handling within Quantum.
    This is an interim solution that deals with an 'ugly' response body,
    whilst keeping backward compatibility.

    Fixes bug 1173284

    Change-Id: Icaab87ad0c8561c0690c8f0a14db815d8886bc71

Changed in quantum:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2013-05-29
Changed in quantum:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in neutron:
milestone: havana-1 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers