| 2017-03-07 04:18:06 |
clayg |
description |
The proxy won't issue DELETE requests to backend storage if the there is an error getting container_info (e.g. 404).
This is probably fine in general, but problematic when trying to clean up dark data in a deleted container.
It's especially annoying if the deleted container was a non-legacy storage policy (i.e. not storage policy index 0) and you have to make the delete request with InternalClient *anyway* - only to still get rejected because the container does not exist (yeah I know... that's why I told you to delete that object!)
Dark data generally happens when you re-introduce hardware that's been out of the cluster for longer than a reclaim age. It's an annoying mess to clean up. When you're already annoyed, because you have to go clean it up (e.g. lp bug #1655608) it'd be nice if InternalClient or the ObjectController didn't try so hard to stand in your way. |
The proxy won't issue DELETE requests to backend storage if the there is an error getting container_info (e.g. 404):
https://github.com/openstack/swift/blob/cf1c44dff0706ec4fa491aa7d3d956d3795ae675/swift/proxy/controllers/obj.py#L712
This is probably fine in general, but problematic when trying to clean up dark data in a deleted container.
It's especially annoying if the deleted container was a non-legacy storage policy (i.e. not storage policy index 0) and you have to make the delete request with InternalClient *anyway* - only to still get rejected because the container does not exist (yeah I know... that's why I told you to delete that object!)
Dark data generally happens when you re-introduce hardware that's been out of the cluster for longer than a reclaim age. It's an annoying mess to clean up. When you're already annoyed, because you have to go clean it up (e.g. lp bug #1655608) it'd be nice if InternalClient or the ObjectController didn't try so hard to stand in your way. |
|
