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

[Stephen Ma]

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?

[Armando Migliaccio (armando-migliaccio)]

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.

[Stephen Ma (stephen-ma)]

Sorry, typo in the title. It should be

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

[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.

[Armando Migliaccio (armando-migliaccio)]

Related documentation bug is:

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

[Armando Migliaccio (armando-migliaccio)]

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)]

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 {})

[Armando Migliaccio (armando-migliaccio)]

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)]

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.

[Armando Migliaccio (armando-migliaccio)]

Thanks Mark, I'll act accordingly.

Cheers,
Armando

[Armando Migliaccio (armando-migliaccio)]

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.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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