)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":39587,"name":"Amir Modarresi","display_name":"Amir Modarresi","email":"seyedamirmodaresi@gmail.com"},"change_message_id":"0e1602245c96a26b0a6e3bd1e1a6cfdf30aa310a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"a9b34d0f_486a4128","updated":"2026-10-27 16:55:48.000000000","message":"Hello Cinder team,\n\nPatchset 3 includes the RBD deferred deletion retention fix and regression tests.\n\nThe ARM64 Zuul jobs and several third-party CI jobs have completed successfully. Some third-party CI jobs have reported failures that still need investigation.\n\nThe change intentionally keeps the new deletion behavior limited to eligible volumes without clone-parent dependencies.\n\nI would appreciate feedback on this approach, particularly the handling of clone dependencies and whether the current scope is appropriate for an initial fix.\n\nThank you for your review.","commit_id":"f34d1f895d00266c1a242831f9c458c9e288b909"},{"author":{"_account_id":39587,"name":"Amir Modarresi","display_name":"Amir Modarresi","email":"seyedamirmodaresi@gmail.com"},"change_message_id":"afb2b350c3098e57f4bbdb7b432c1b7a9cc7a80b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"4020eb79_9e9524df","updated":"2026-10-27 19:09:54.000000000","message":"Hello Cinder team,\n\nPatchset 3 includes the RBD deferred deletion retention fix and regression tests.\n\nThe ARM64 Zuul jobs and several third-party CI jobs have completed successfully. Some third-party CI jobs have reported failures that still need investigation.\n\nThe change intentionally keeps the new deletion behavior limited to eligible volumes without clone-parent dependencies.\n\nI would appreciate feedback on this approach, particularly the handling of clone dependencies and whether the current scope is appropriate for an initial fix.\n\nThank you for your review.","commit_id":"81ea5d50d3418aaba2cb81377bbcef3ff1ff7f23"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"5a3333238770a66ae91b56b5288878088d039964","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"fb6c7558_511b6df8","updated":"2026-11-02 15:50:02.000000000","message":"We\u0027re going to have to discuss this at cinder midcycle meeting #1 [0].\n\nThe issue as I see it is that the block storage provided by Ceph is not really block storage, but block storage simulated by an object store, and as a result, some of the normal block storage operations that would not create dependencies in a real block storage backend, create dependencies in RBD, and this impacts end users who are blocked from deleting resources that are conceptually independent (and should be deleteable) but are actually linked in Ceph and cannot be deleted.  The Cinder project used deferred deletion so that the item could marked as deleted in cinder, but not be deleted from the backend (because Ceph wouldn\u0027t allow it) until the associated resources that are blocking deletion were themselves deleted.  In my opinion, it was never intended as a mechanism for keeping arbitrary resources around for a guaranteed amount of time.  As Ceph has evolved, Ceph has introduced various features (e.g., the trash, clone v2 api) that make it possible for cinder to offload the work we were doing to make Ceph appear to be a normal block storage backend back to Ceph itself.  \n\nSo before we merge this patch, we need to iron out exactly what the cinder community\u0027s attitude toward RBD is.\n\n\n[0] https://releases.openstack.org/indri/schedule.html#cinder-midcycle-meeting-1","commit_id":"81ea5d50d3418aaba2cb81377bbcef3ff1ff7f23"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"ad03e8100fb5253094ba4b95dee0b811f661c257","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"af521768_cfce5f66","in_reply_to":"cff29099_851a6ac7","updated":"2026-11-02 22:45:14.000000000","message":"I haven\u0027t read through the discussion on https://review.opendev.org/c/openstack/cinder/+/835384 but my recollection is that the intent of the refactoring was to eventually eliminate the need for the cinder-side deferred deletion.  I looked in the cinder youtube channel, and it looks like the recordings only start in Train, so we\u0027ve probably lost the history around the original spec.  We\u0027ll need some discussion to figure out exactly where we want to go on this.","commit_id":"81ea5d50d3418aaba2cb81377bbcef3ff1ff7f23"},{"author":{"_account_id":39587,"name":"Amir Modarresi","display_name":"Amir Modarresi","email":"seyedamirmodaresi@gmail.com"},"change_message_id":"b9be63d3066207d73285ddf873bf31e76f0c1013","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"cff29099_851a6ac7","in_reply_to":"fb6c7558_511b6df8","updated":"2026-11-02 17:04:10.000000000","message":"Hi Brian,\n\nThank you for the detailed explanation. I understand your concern about the original purpose of deferred deletion and the distinction between handling RBD dependencies and providing guaranteed data retention or recovery.\n\nI agree that Cinder should not promise recoverability simply because an image has been moved to RBD trash. That is not the intention of this patch.\n\nHowever, while investigating this issue, I found some historical context that I believe is relevant.\n\nThe original Stein specification explicitly proposed optional asynchronous deletion using `trash_move()` instead of `remove()` when `enable_deferred_deletion` is enabled. It also defined `deferred_deletion_delay` as the time before an image becomes eligible for purging:\n\nhttps://specs.openstack.org/openstack/cinder-specs/specs/stein/support-deferred-deletion-in-rbd.html\n\nThis behavior was implemented in earlier Cinder releases, including Cinder 14.0.0 and 22.0.0.\n\nThe December 2023 change that introduced the direct `remove()` fast path for improved clone dependency handling appears to have changed this behavior for ordinary volumes:\n\nhttps://github.com/openstack/cinder/commit/1a675c9aa178c6d9c6ed10fd98f086c46d350d3f\n\nI do not want to assume this was an unintended regression.\n\nThe current proposal is intentionally limited: it keeps deferred deletion disabled by default, uses the existing configuration options, and preserves the existing deletion paths for internal operations and clone-parent scenarios.\n\nI also recognize that asynchronous deletion with a configurable delay has operational consequences, including backend space consumption and potential interactions with RBD dependencies.\n\nMy main question is:\n\n**Was the change in deferred deletion behavior introduced by the December 2023 refactoring intentional, and should `enable_deferred_deletion` still support the originally documented optional asynchronous trash-based deletion behavior, or is its intended scope now limited to dependency-related cleanup?**\n\nI would appreciate clarification on the intended behavior so that I can align this proposal with the Cinder project\u0027s current design direction.\n\nThank you again for your guidance and review.","commit_id":"81ea5d50d3418aaba2cb81377bbcef3ff1ff7f23"}],"cinder/tests/unit/volume/drivers/test_rbd.py":[{"author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"tag":"autogenerated:zuul:check","change_message_id":"4af008783e9b0646e0e0bb8e20634067934043bb","unresolved":false,"context_lines":[{"line_number":972,"context_line":"        self.driver.rbd.RBD.return_value.trash_move.assert_not_called()"},{"line_number":973,"context_line":""},{"line_number":974,"context_line":""},{"line_number":975,"context_line":"    @common_mocks"},{"line_number":976,"context_line":"    def test_deferred_deletion(self):"},{"line_number":977,"context_line":"        delay \u003d 3600"},{"line_number":978,"context_line":"        drv \u003d self._make_drv({"}],"source_content_type":"text/x-python","patch_set":4,"id":"28b47f27_ce9b8c0d","line":975,"updated":"2026-10-27 18:09:07.000000000","message":"pep8: E303 too many blank lines (2)","commit_id":"f34d1f895d00266c1a242831f9c458c9e288b909"},{"author":{"_account_id":39587,"name":"Amir Modarresi","display_name":"Amir Modarresi","email":"seyedamirmodaresi@gmail.com"},"change_message_id":"a15f1bc02912bd9f2095b037a07243bd0b844b9b","unresolved":false,"context_lines":[{"line_number":972,"context_line":"        self.driver.rbd.RBD.return_value.trash_move.assert_not_called()"},{"line_number":973,"context_line":""},{"line_number":974,"context_line":""},{"line_number":975,"context_line":"    @common_mocks"},{"line_number":976,"context_line":"    def test_deferred_deletion(self):"},{"line_number":977,"context_line":"        delay \u003d 3600"},{"line_number":978,"context_line":"        drv \u003d self._make_drv({"}],"source_content_type":"text/x-python","patch_set":4,"id":"e39ef0eb_7ac6c11e","line":975,"in_reply_to":"28b47f27_ce9b8c0d","updated":"2026-10-27 18:54:13.000000000","message":"It was corrected","commit_id":"f34d1f895d00266c1a242831f9c458c9e288b909"}]}