Update patch set 6

Patch Set 6:

(5 comments)

Patch-set: 6
Attention: {"person_ident":"Gerrit User 32919 \u003c32919@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_16643\u003e replied on the change"}

8521b194e420ef7de057ee72c52e531561230d65

@@ -33,6 +33,109 @@
       "message": "thanks for your change. let\u0027s merge this.",
       "revId": "8521b194e420ef7de057ee72c52e531561230d65",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": false,
+      "key": {
+        "uuid": "3706aa01_69c08009",
+        "filename": "/PATCHSET_LEVEL",
+        "patchSetId": 6
+      },
+      "lineNbr": 0,
+      "author": {
+        "id": 16643
+      },
+      "writtenOn": "2024-01-21T21:03:21Z",
+      "side": 1,
+      "message": "I\u0027m late to provide feedback here, but still noting this for posterity. Please feel free to address comments, or changes with a follow up patch, or during code reviews",
+      "revId": "8521b194e420ef7de057ee72c52e531561230d65",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "5cd97fc8_cbb74f7e",
+        "filename": "specs/caracal/deferred_deletion.rst",
+        "patchSetId": 6
+      },
+      "lineNbr": 48,
+      "author": {
+        "id": 16643
+      },
+      "writtenOn": "2024-01-21T21:03:21Z",
+      "side": 1,
+      "message": "is this status required? \"error_deleting\" exists, and suffices imo. How is this different?",
+      "range": {
+        "startLine": 48,
+        "startChar": 48,
+        "endLine": 48,
+        "endChar": 72
+      },
+      "revId": "8521b194e420ef7de057ee72c52e531561230d65",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "230559c4_1736bbd7",
+        "filename": "specs/caracal/deferred_deletion.rst",
+        "patchSetId": 6
+      },
+      "lineNbr": 48,
+      "author": {
+        "id": 16643
+      },
+      "writtenOn": "2024-01-21T21:03:21Z",
+      "side": 1,
+      "message": "perhaps \"deferred_deleting\" is better here?",
+      "range": {
+        "startLine": 48,
+        "startChar": 23,
+        "endLine": 48,
+        "endChar": 41
+      },
+      "revId": "8521b194e420ef7de057ee72c52e531561230d65",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "7803d3ad_55a8bb36",
+        "filename": "specs/caracal/deferred_deletion.rst",
+        "patchSetId": 6
+      },
+      "lineNbr": 52,
+      "author": {
+        "id": 16643
+      },
+      "writtenOn": "2024-01-21T21:03:21Z",
+      "side": 1,
+      "message": "a boolean configuration option like this should be named with a prefix \"is_\" and a suffix if the option is to turn something on\n\nperhaps:\n\n\"is_deferred_deletion_enabled\"",
+      "range": {
+        "startLine": 52,
+        "startChar": 32,
+        "endLine": 52,
+        "endChar": 49
+      },
+      "revId": "8521b194e420ef7de057ee72c52e531561230d65",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "252e837c_f7d3aeb2",
+        "filename": "specs/caracal/deferred_deletion.rst",
+        "patchSetId": 6
+      },
+      "lineNbr": 55,
+      "author": {
+        "id": 16643
+      },
+      "writtenOn": "2024-01-21T21:03:21Z",
+      "side": 1,
+      "message": "what really is the advantage of not sending a deletion request to the backend right away? \n\ni don\u0027t mind the introduction of a loop.. but i thought the purpose of this originally was really about giving backends a way to take time on deletion without blocking the share manager\u0027s call. \n\n\ndeletion in the backend may be an asynchronous process.. today, we are expecting the drivers to delete shares and snapshots in a synchronous manner, or, atleast pretend to do that.. \n\n\nat the PTG, we discussed the following workflow:\n\n1) User deletes a share\n2) API request goes to the share manager, share manager asks the driver to process deletion\n3) Driver says it needs more time\n4) Share manager sets the share\u0027s status to an internal state (user still sees \"deleting\" in the API...)\n5) Quota is released\n6) share manager periodically asks the driver to delete the share, driver can continue to tell the share manager that it needs more time... eventually, if the driver sees that the share is deleted, it can tell the share manager so, and the share manager cleans up the database records.\n\n\n\nIn this spec, you\u0027re proposing a global config opt that allows users to immediately regain quota, and deferred deletions are still synchronous/atomic between the manager and the driver.\n\nI don\u0027t particularly have a problem with regaining quota immediately, but, I was hoping we\u0027d address the synchronicity issue of the deletion in the driver.",
+      "revId": "8521b194e420ef7de057ee72c52e531561230d65",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
     }
   ],
   "submitRequirementResults": [