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

David Kranz dkranz at redhat.com
Fri Jun 13 16:14:43 UTC 2014


On 06/12/2014 08:27 PM, GHANSHYAM MANN wrote:
>
>
>
> On Fri, Jun 13, 2014 at 8:42 AM, Christopher Yeoh <cbkyeoh at gmail.com 
> <mailto:cbkyeoh at gmail.com>> wrote:
>
>     On Fri, Jun 13, 2014 at 7:05 AM, David Kranz <dkranz at redhat.com
>     <mailto: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
>
> I was also going through the testing of delete operation in tempest 
> and there is not much consistency.
> If *strictly* testing, we should not have any wait for 204 response. 
> If any operation still in progress and return 204 then its a false 
> return  and tempest should be able to catch those as it can break user 
> app also. Tempest should report fail so that specific project can fix 
> that operation or return code (exception in case of backward 
> compatibility).
>
Right. I think it makes sense for all the delete apis that return 204 to 
have tests that try to do another delete immediately and also do a get. 
But for reasons Jay pointed out we will have to leave the "cleanup" 
deletes doing a loop check.

  -David
> Ghanhsyam Mann
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Thanks & Regards
> Ghanshyam Mann
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


More information about the OpenStack-dev mailing list