DeleteContainer() and DeleteBlob() do not block until the operation is completed

[Raphaël Badin]

DeleteContainer() and DeleteBlob() (storage_base.go) both expect a http.StatusAccepted response from the server but none of them block until the operation is completed.

[Jeroen T. Vermeulen (jtv)]

It does not appear as if the API supports blocking on completion of these operations.

Here are the avenues I explored:

 * The management API documentation shows no way to query status information for them. There is a request ID in Azure's response for these operations, but unlike the request IDs we get from the management API these have "reporting problems to Microsoft" as their only documented use:

    http://msdn.microsoft.com/en-us/library/windowsazure/dd573365.aspx

 * Using the management API's Get Operation Status call does not seem to work on these request IDs. It returns 404: "ResourceNotFound - The operation request ID was not found."

 * Whatever item is being deleted immediately becomes invisible, so it doesn't look as if we can poll for it to disappear.

The Azure documentation describes the deletion requests as "marking for deletion," and the completion we want to wait for as "garbage collection." That makes it unlikely that there is any built-in way to poll for the latter.

There are other things we could try:

 * Block and retry when creation of a new item fails with a 409 (Conflict) error, because it might mean that a previous item of the same name is still being deleted.

 * Rename objects to randomized names just prior to deletion, to minimize the risk of a clash on subsequent re-creation.

[Jeroen T. Vermeulen (jtv)]

We had assumed that what gwacl did here was poor use of the Azure API. As it turns out, it's not. It's a problem with Azure's API itself, and one that could be addressed better at that end (delete name records immediately when deleting the items they describe; ignore name clashes with deleted items; change names of deleted items to something that clients can not create for themselves; return a more recognizable error when a newly created item conflicts with a deleted one). Working around the problem adds moving parts and risks, and the problem may just go away in a future version of Azure. Until then, this is a nuisance rather than a fatal problem.

For all these reasons I'm downgrading this bug to Low priority.