auditor recon dump is not consistent on new nodes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Confirmed
|
Low
|
Unassigned |
Bug Description
When you first bring up a node, and there's no data to audit the recon dump includes an empty disk:
ubuntu@
{
"object_
"object_
"object_
"object_
"object_
"object_
"replicatio
"replicatio
"failure": 0,
"remove": 0,
"rsync": 0,
"start": 1500319107.347603,
"success": 0
},
"replicatio
}
Then if you run it *again* the keys are missing:
ubuntu@
{
"object_
"object_
"object_
"object_
"replicatio
"replicatio
"failure": 0,
"remove": 0,
"rsync": 0,
"start": 1500319107.347603,
"success": 0
},
"replicatio
}
Easiest way to observe is just running a single auditor on a brand new saio:
swift-init object-auditor once -nv -c 4
Then check the recon dump between passes, you can also set your run_pause to 0 and watch it toggle.
I think it would be better if once the auditor finished it wrote empty stats and the keys stayed there.
Changed in swift: | |
status: | New → Confirmed |
Reviewed: https:/ /review. openstack. org/484375 /git.openstack. org/cgit/ openstack/ swift/commit/ ?id=c2e59b9b8b4 3e5846c0fe20cfd 7810bbc0291cad
Committed: https:/
Submitter: Jenkins
Branch: master
commit c2e59b9b8b43e58 46c0fe20cfd7810 bbc0291cad
Author: Alistair Coles <email address hidden>
Date: Mon Jul 17 14:29:53 2017 +0100
Make dict deletion idempotent in dump_recon_cache
Calling dump_recon_cache with a key mapped to an empty dict value
causes the key to be removed from the cache entry. Doing the same
again causes the key to be added back and mapped an empty dict, and
the key continues to toggle as calls are repeated. This behavior is
seen on the Related-Bug report.
This patch fixes dump_recon_cache to make deletion of a key
idempotent. This fix is needed for the Related-Change which makes use
of empty dicts with dump_recon_cache to clear unwanted keys from the
cache.
The only caller that currently set empty dict values is
obj/auditor.py where the current intended behavior would appear to be
as per this patch.
Related-Change: I28925a37f3985c 9082b5a06e76af4 dc3ec813abe c2c7bd95809cec6 c5e18e9301e
Related-Bug: #1704858
Change-Id: If9638b4e7dba0e