On 06/12/2014 08:27 PM, GHANSHYAM MANN wrote:
On Fri, Jun 13, 2014 at 8:42 AM, Christopher Yeoh <cbky...@gmail.com
<mailto:cbky...@gmail.com>> wrote:
On Fri, Jun 13, 2014 at 7:05 AM, David Kranz <dkr...@redhat.com
<mailto:dkr...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks & Regards
Ghanshyam Mann
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
