object-expirer logs un-needed traceback on expected 404/412 until marker reclaims
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
In my current swift deployment we are seeing a large amount of errors from the object-expirer.
Here is an example from our logs:
object-expirer: Exception while deleting object 1493251104 1493688825-
Unexpected response: 412 Precondition
Failed:
#012 Traceback (most recent call last):
#012 File "/usr/lib/
#012 File "/usr/lib/
#012 (2,))
#012 File "/usr/lib/
#012 _('Unexpected response: %s') % resp.status, resp)
#012 UnexpectedResponse: Unexpected response: 412 Precondition Failed (txn: txfde64949aff04
Now I have reviewed the source code and see that this is because the x-delete-at for the object is not matching the x-if-delete-at header. If this is not a bug then what could the cause be for the values to be out of sync?
I think when an object gets re-uploaded it's possible the old expirer entry doesn't get reaped.
1) Is the object *supposed* to be expired - can you check on all primary on-disk locations using swift-get-nodes or similar?
2) Does the expirer keep retrying or is the .expiring_objects marker cleaned up
It's possible the traceback is benign and everything is working as expected except for the annoying log message.