race condition where auditor may start before swift.conf
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
puppet-swift |
Fix Released
|
High
|
Emilien Macchi |
Bug Description
Deploying Swift with this manifest: https:/
Result:
Look at the timestamps, the swift auditor is started before /etc/swift/
The proxy was started later, thus using the new hash_suffix and storing the object in a different place than the auditor expects.
[root@swift-
Apr 9 16:18:32 os-ci-test10 object-auditor: Begin object audit "forever" mode (ZBF)
Apr 9 16:18:32 os-ci-test10 object-auditor: Begin object audit "forever" mode (ZBF)
Apr 9 16:18:32 os-ci-test10 object-auditor: Begin object audit "forever" mode (ALL)
Apr 9 16:18:32 os-ci-test10 object-auditor: Begin object audit "forever" mode (ALL)
Apr 9 16:18:32 os-ci-test10 object-auditor: Object audit (ZBF) "forever" mode completed: 0.00s. Total quarantined: 0, Total errors: 0, Total files/sec: 0.00, Total bytes/sec: 0.00, Auditing time: 0.00, Rate: 0.00
[root@swift-
File: '/etc/swift/
Size: 55 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 787453 Links: 1
Access: (0660/-rw-rw----) Uid: ( 160/ swift) Gid: ( 160/ swift)
Context: system_
Access: 2015-04-09 16:18:36.429054332 +0000
Modify: 2015-04-09 16:18:35.640024769 +0000
Change: 2015-04-09 16:18:35.640024769 +0000
Birth: -
[root@swift-
root 4745 0.0 0.0 112612 688 pts/0 S+ 18:43 0:00 grep --color=auto swift-proxy
swift 24786 0.0 0.1 278928 30776 ? Ss 16:42 0:00 /usr/bin/python /usr/bin/
swift 24811 0.0 0.1 282276 32508 ? S 16:42 0:02 /usr/bin/python /usr/bin/
swift 24812 0.0 0.1 282420 32548 ? S 16:42 0:02 /usr/bin/python /usr/bin/
Changed in puppet-swift: | |
importance: | Undecided → High |
assignee: | nobody → Emilien Macchi (emilienm) |
Changed in puppet-swift: | |
milestone: | none → 6.0.0 |
Changed in puppet-swift: | |
status: | Fix Committed → Fix Released |
The impact of this is that all objects will be quarantined and are no longer available. It only happens directly after installation; if the service or node is restarted before storing objects you will never see this bug.
Note that this requires a lot of manual work for an operators, because you need to manually move the quarantined objects back to their original location.