[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