Update patch set 6

Patch Set 6:

(1 comment)

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

@@ -226,6 +226,24 @@
       "parentUuid": "252e837c_f7d3aeb2",
       "revId": "8521b194e420ef7de057ee72c52e531561230d65",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "94a15414_86235d69",
+        "filename": "specs/caracal/deferred_deletion.rst",
+        "patchSetId": 6
+      },
+      "lineNbr": 55,
+      "author": {
+        "id": 16643
+      },
+      "writtenOn": "2024-01-23T00:55:36Z",
+      "side": 1,
+      "message": "Yes; I get (and support) the aspect of releasing quota immediately. However, wouldn\u0027t it make your implementation easier too if you allowed for deferred deletion to be requested by the driver?\n\n\u003e 1. driver now first calculate/decide whether it needs more time or not.\n\nYes. This is crucial.. Today, there\u0027s no such mechanism. If a driver figures out that deletion will take time, it just has to implement a loop and wait. This causes a thread in the share manager/driver process to be wasted on waiting. An example is the NetApp driver canceling clone splits and waiting on clone split cancelation.. instead, if the driver saw that a share was busy with clone split, it could either return and wait for clone split to complete, or, cancel the clone split, and return to the share manager and wait for the deletion request to come again to retry deleting the share. \n\n\n\u003e 2. Even if driver replies that no more time is needed, there is no guarantee that driver wont take more time.\n\n\nHmm this is true. We improved the \"create_share\" workflow in a past release to optionally become a two-step workflow. This allowed drivers to become more efficient. For example, the NetApp and CephFS drivers create shares from snapshot in a deferred way using this two step approach. It\u0027s a design enhancement that we can reap benefits of, over time. \n\n\u003e 3. If driver says it needs more time, we are anyways releasing quota at point 5). then why wait for driver to respond for time, just release quota and let driver handle deletion in its own time.\n\n\nDoing this allows you to reuse existing code instead of adding code in the API layer to release quota.",
+      "parentUuid": "1116b838_7dbff72e",
+      "revId": "8521b194e420ef7de057ee72c52e531561230d65",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
     }
   ],
   "submitRequirementResults": [