Open Stack

On Fri, Jun 13, 2014 at 8:42 AM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:

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

Ghanhsyam Mann

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks & Regards
Ghanshyam Mann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/628a7497/attachment.html>