neutron

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

Bug #1173284 reported by Stephen Ma
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Armando Migliaccio
neutron 2013.2 "havana"

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 http://10.133.10.219:9696/v2.0/routers/8bf5fbad-18d7-43c2-9a87-1819cca6ebe4/remove_router_interface.json -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
stack@ubuntu-2:/tmp$

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
Armando Migliaccio (armando-migliaccio)
Changed in quantum:
status: New → Incomplete
status: Incomplete → New
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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
Revision history for this message
Stephen Ma (stephen-ma) wrote :

Sorry, typo in the title. It should be

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

Salvatore Orlando (salvatore-orlando)
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)
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote : Re: quantum remote-router-interface should return 204 and no response body

Related documentation bug is:

https://bugs.launchpad.net/openstack-api-site/+bug/1174481

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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.

Revision history for this message
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 {})

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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.

Revision history for this message
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.

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

Thanks Mark, I'll act accordingly.

Cheers,
Armando

summary: - quantum remote-router-interface should return 204 and no response body
+ quantum remote-router-interface should not return a 'null' body
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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:

https://bugs.launchpad.net/openstack-api-site/+bug/1174481

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.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (master)

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

Changed in quantum:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to quantum (master)

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)
Changed in quantum:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in neutron:
milestone: havana-1 → 2013.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.