)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":10058,"name":"Erlon R. Cruz","email":"erlon.rodrigues.cruz@canonical.com","username":"sombrafam"},"change_message_id":"9df98429384ab839f2ff265d135ef66e37be11d6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0f599be6_2c9a936d","updated":"2026-05-22 16:29:14.000000000","message":"Hey Sam, thanks a lot for your patches (this one and the other two). For this specific patch, I don\u0027t have enough expertise to provide a voting, but I can tell you that since this is a very sensitive path, it will require thorough reasoning on the considerations you made for this implementation. You can refer to the message added by this commit as a reference [1].\n\nOne edge case you will need to explain for example, is how the new code will behave during an upgrade, where deployment without your fix and old volume structures will behave after the upgrade.\n\n[1] https://review.opendev.org/c/openstack/cinder/+/835384","commit_id":"c06ff0b171ba25f5fbbdcca43353759a5cc5a945"},{"author":{"_account_id":37798,"name":"Sam Clippinger","display_name":"samatwork","email":"sam.clippinger@garmin.com","username":"samatwork","status":"Garmin International"},"change_message_id":"3ec5bb855fbd586e9bf55b3261b755cbad6bf921","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"17599b84_aad32e6b","in_reply_to":"0f599be6_2c9a936d","updated":"2026-05-27 01:06:51.000000000","message":"Thanks for the feedback!  I\u0027ll update my commit message with a real writeup (instead of my usual terse one-liner).","commit_id":"c06ff0b171ba25f5fbbdcca43353759a5cc5a945"},{"author":{"_account_id":39509,"name":"Lucas HENRY","display_name":"Lucas HENRY","email":"lucas.henry@ovhcloud.com","username":"polyedre"},"change_message_id":"795c173efda53e9ba1d1248d40a23a09fa31159c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"b33fceb1_f515b855","updated":"2026-10-06 14:51:27.000000000","message":"Hi Sam,\n\nWe\u0027re hitting this bug too: deleted clones leave the .clone_snap on the parent, and parents already deleted in Cinder (volume-*.deleted) are\nnever removed, so Ceph capacity slowly leaks.\n\nAre you still planning to take this further? If you don\u0027t have the bandwidth, we\u0027d be happy to co-author it. We\u0027d keep this change (your\nChange-Id and authorship, with us as Co-Authored-By) and do the work Erlon asked for:\n\n- a full write-up of the new delete flow, in the style of 835384;\n- the upgrade path: how pools that already contain leaked .deleted parents and orphaned .clone_snap snapshots behave once the fix is deployed,\nand how the fix behaves with mixed old/new cinder-volume services;\n- failure semantics when the parent walk fails after the child image is already gone;\n- tests against a real Ceph cluster covering clone format v1/v2, enable_deferred_deletion on/off, and parent chains of several levels, with\nbefore/after rbd ls / snap ls / trash ls output attached.\n\nOn the code side, we\u0027d also suggest moving the retry/trash fallback into a small helper so the fast path and slow path converge on the same\nparent walk, instead of threading a deleted flag through the function.\n\nIf we don\u0027t hear back in a couple of weeks, we\u0027ll go ahead and upload a new patch set along those lines. Happy to coordinate however suits you","commit_id":"f340e435ea75b9a09bd29970f82606c9cf544d73"},{"author":{"_account_id":37798,"name":"Sam Clippinger","display_name":"samatwork","email":"sam.clippinger@garmin.com","username":"samatwork","status":"Garmin International"},"change_message_id":"1396d9847104351cec6b1ce82078225cb3ea5bb8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"cad6afe3_67fc8de2","in_reply_to":"b33fceb1_f515b855","updated":"2026-10-07 15:04:04.000000000","message":"Please feel free to take over!  Restructure as you see fit!\n\nMy rant:\n\nOn this and other Cinder patches, the amount of time I\u0027ve spent trying to satisfy Cinder\u0027s CI system has long exceeded what I can give.  And the random drive-by downvotes from developers with no followup has been extremely frustrating.  I know everyone is busy, everyone has a day job, everyone\u0027s time is limited, etc etc, but I\u0027m busy too and I\u0027ve hit my limit.\n\nI\u0027ve got some bigger Cinder patches that I had planned to propose but at this point... forget it!  I can\u0027t even get this very trivial fix pushed through; there\u0027s no way I\u0027ve got time to argue about adding API endpoints.  We\u0027ll just keep carrying our patches internally.","commit_id":"f340e435ea75b9a09bd29970f82606c9cf544d73"},{"author":{"_account_id":39509,"name":"Lucas HENRY","display_name":"Lucas HENRY","email":"lucas.henry@ovhcloud.com","username":"polyedre"},"change_message_id":"5235eda58bd10907b712f59aa73696c9b28c8842","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"4a091162_ca7efcdf","updated":"2026-10-15 12:41:19.000000000","message":"@erlon.rodrigues.cruz@canonical.com, PS6 addresses your PS3 feedback: the commit message now describes the full delete flow, the upgrade and mixed-version behaviour, how existing pools with leaked .clone_snap / *.deleted images behave, and the known limitations. Would you mind taking another look?","commit_id":"b4a74ed12a9c5d32883dc016f29d5e19ccdfcbeb"},{"author":{"_account_id":39509,"name":"Lucas HENRY","display_name":"Lucas HENRY","email":"lucas.henry@ovhcloud.com","username":"polyedre"},"change_message_id":"2d848aae5952e111c24331e1bc5c0d94516c4682","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"71e53dc9_b0cdbfb6","updated":"2026-10-09 09:34:56.000000000","message":"I\u0027m taking this over, as Sam agreed.\n\nHere\u0027s what changed in this new patchset:\n- the parent walk now runs after any successful removal, fast path included (that is the fix for the bug);\n- a failure in the walk is logged instead of failing the delete. The image is already gone at that point, so a retried delete returns early on ImageNotFound and never reaches the walk: raising only left the volume in error_deleting;\n- the retry/trash fallback is moved unchanged into `_remove_or_trash_volume()`, so that both paths fall through to the walk;\n- unit tests for the fast path with a `.deleted` parent, a live parent, a walk failure, and deferred deletion; release note.\n\nI tested it against a Ceph 17.2 cluster. I checked v1 and v2 clone format, with `enable_deferred_deletion` off and on. Tests included creating volumes through the driver, deleting them, purging the trash and checking the pool was empty.\n\nI was able to confirm that before the patch, some volumes were leaked. With that patch, most of the happy-path are properly cleaned up. However, there\u0027s still some issues with nested clones (we currently check only one level above and below).","commit_id":"b4a74ed12a9c5d32883dc016f29d5e19ccdfcbeb"}]}