[openstack-dev] [qa] Meaning of 204 from DELETE apis

Christopher Yeoh cbkyeoh at gmail.com
Thu Jun 12 23:42:28 UTC 2014


On Fri, Jun 13, 2014 at 7:05 AM, David Kranz <dkranz at redhat.com> wrote:

> On 06/12/2014 05:27 PM, Jay Pipes wrote:
>
>> On 06/12/2014 05:17 PM, David Kranz wrote:
>>
>>> Tempest has a number of tests in various services for deleting objects
>>> that mostly return 204. Many, but not all, of these tests go on to check
>>> that the resource was actually deleted but do so in different ways.
>>> Sometimes they go into a timeout loop waiting for a GET on the object to
>>> fail. Sometimes they immediately call DELETE again or GET and assert
>>> that it fails. According to what I can see about the HTTP "spec", 204
>>> should mean that the object was deleted. So is waiting for something to
>>> disappear unnecessary? Is immediate assertion wrong? Does this behavior
>>> vary service to service? We should be as consistent about this as
>>> possible but I am not sure what the expected behavior of all services
>>> actually is.
>>>
>>
>> The main problem I've seen is that while the resource is deleted, it
>> stays in a deleting state for some time, and quotas don't get adjusted
>> until the server is finally set to a terminated status.
>>
> So you are talking about nova here. In tempest I think we need to more
> clearly distinguish when delete is being called to test the delete api vs.
> as part of some cleanup. There was an irc discussion related to this
> recently.  The question is, if I do a delete and get a 204, can I expect
> that immediately doing another delete or get will fail? And that question
> needs an answer for each api that has delete in order to have proper tests
> for delete.
>

So if the deletion does not occur before the call returns the API should be
returning 202 rather than 204. The tasks API should help clarify things
here as a task handle will be returned for long running things and you can
query progress rather than polling by listing objects etc.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/7251a9ae/attachment.html>


More information about the OpenStack-dev mailing list