Object DELETE returning 503 for (404, 204)

Bug #1692380 reported by hwang, sungi
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Invalid
Undecided
Unassigned

Bug Description

- Swift structure Account: 3Copy Container: 3Copy Object: 2Copy (2 replicas)

- Swift version: icehouse

- Issue: Object DELETE returning 503 for (404, 204)

When deleting from Swift, proxy.error will result in the following error: Object DELETE returning 503 for (404, 204)

Object delete DELETE returning 503 for (404, 204) error when executing delete When restarting the proxy server daemon, the deletion is normal again.
By the way, restarting proxy server daemon, swift daemon is not deleted at present.

If you delete the files in the container and check for an error 503, The file with the error has not been deleted already. Again, when the client executes the deletion, it will repeatedly stop the deletion with a 503 error.

Container access to the database I checked the object file in the container for the actual 503 error. I looked up each field value Size: 0, etag: deleted, deleted: 1. Compared to other files that have not been deleted, the values ​​of the above fields are incorrect, and even if a 503 error occurs, it appears to have been deleted.

Again, swift-get-nodes queries the disk for the existence of the deleted data. The object file does not exist.

Of course, the above method has been successfully executed without any abnormality (even if a 503 error occurs during the deletion, when the proxy daemon is restarted, the deletion is normally performed again).
There is no change in the method of deletion.

Object DELETE returning 503 for (404, 204) I want to solve.

hwang, sungi (sungiing)
summary: - Object DELETE returning 503 for (404, 204)
+ (404, 204)에 대해 503을 반환하는 객체 DELETE
description: updated
hwang, sungi (sungiing)
description: updated
hwang, sungi (sungiing)
summary: - (404, 204)에 대해 503을 반환하는 객체 DELETE
+ Object DELETE returning 503 for (404, 204)
hwang, sungi (sungiing)
Changed in swift:
assignee: nobody → hwang, sungi (sungiing)
assignee: hwang, sungi (sungiing) → nobody
clayg (clay-gerrard)
description: updated
Revision history for this message
clayg (clay-gerrard) wrote :

For 2-replica policies this should have been fixed with f4d3facd [1]

Can you test with master and confirm?

I'm showing that as being in swift since 2.2

Icehouse was EOL Apr 17, 2014

1. https://review.openstack.org/#/c/114120/

Revision history for this message
hwang, sungi (sungiing) wrote :

The Internet network currently used by the company is as follows.
Because it is an in-house dedicated network, access from the server to the outside is blocked, and the Internet can not be accessed.
So, can you tell me how to get and patch an archive tar file?

Revision history for this message
Tim Burke (1-tim-z) wrote :

How did you get swift installed initially? Can you use a similar mechanism to upgrade to a supported version?

In addition to the 404-specific fix Clay found, there's also https://github.com/openstack/swift/commit/29544a9 (included in 2.8.0+) that lowers the quorum size for 2-replica policies. I'm fairly certain this should be thoroughly fixed on newer versions of swift.

Revision history for this message
Thiago da Silva (thiagodasilva) wrote :

I'm marking this bug as invalid for now, please feel free to re-open if you are still running into this issue with the latest code.

Changed in swift:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.