Update patch set 6
Patch Set 6:
(4 comments)
Patch-set: 6
Attention: {"person_ident":"Gerrit User 32919 \u003c32919@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_32919\u003e replied on the change"}
This commit is contained in:
Gerrit User 32919
Gerrit Code Review
parent
58abfc1b03
commit
fff7ab2176
|
|
@ -97,6 +97,54 @@
|
|||
"revId": "8521b194e420ef7de057ee72c52e531561230d65",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": false,
|
||||
"key": {
|
||||
"uuid": "a2a8b7fa_bcf64e02",
|
||||
"filename": "specs/caracal/deferred_deletion.rst",
|
||||
"patchSetId": 6
|
||||
},
|
||||
"lineNbr": 48,
|
||||
"author": {
|
||||
"id": 32919
|
||||
},
|
||||
"writtenOn": "2024-01-22T05:40:08Z",
|
||||
"side": 1,
|
||||
"message": "error_deleting is something user can see and reset to error and try for deletion again. Error_deferred_deleting shares wont be listed in share list command since their quota is already claimed.\n1. Admin can delete them where they will be removed directly from DB\n2. Or periodic task checking for shares deferred_deleting also will check for error_deferred_deleting (updated before \u003e 30 mins) and tries to ask driver to delete again.\n\nin short error_deferred_deleting is a state where only admin can see those shares and delete (if want else periodic task also take care of it)",
|
||||
"parentUuid": "5cd97fc8_cbb74f7e",
|
||||
"range": {
|
||||
"startLine": 48,
|
||||
"startChar": 48,
|
||||
"endLine": 48,
|
||||
"endChar": 72
|
||||
},
|
||||
"revId": "8521b194e420ef7de057ee72c52e531561230d65",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": false,
|
||||
"key": {
|
||||
"uuid": "c324013c_a5221ec5",
|
||||
"filename": "specs/caracal/deferred_deletion.rst",
|
||||
"patchSetId": 6
|
||||
},
|
||||
"lineNbr": 48,
|
||||
"author": {
|
||||
"id": 32919
|
||||
},
|
||||
"writtenOn": "2024-01-22T05:40:08Z",
|
||||
"side": 1,
|
||||
"message": "Done",
|
||||
"parentUuid": "230559c4_1736bbd7",
|
||||
"range": {
|
||||
"startLine": 48,
|
||||
"startChar": 23,
|
||||
"endLine": 48,
|
||||
"endChar": 41
|
||||
},
|
||||
"revId": "8521b194e420ef7de057ee72c52e531561230d65",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
|
|
@ -120,6 +168,30 @@
|
|||
"revId": "8521b194e420ef7de057ee72c52e531561230d65",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": false,
|
||||
"key": {
|
||||
"uuid": "efcc4fde_93a9d6d5",
|
||||
"filename": "specs/caracal/deferred_deletion.rst",
|
||||
"patchSetId": 6
|
||||
},
|
||||
"lineNbr": 52,
|
||||
"author": {
|
||||
"id": 32919
|
||||
},
|
||||
"writtenOn": "2024-01-22T05:40:08Z",
|
||||
"side": 1,
|
||||
"message": "Done",
|
||||
"parentUuid": "7803d3ad_55a8bb36",
|
||||
"range": {
|
||||
"startLine": 52,
|
||||
"startChar": 32,
|
||||
"endLine": 52,
|
||||
"endChar": 49
|
||||
},
|
||||
"revId": "8521b194e420ef7de057ee72c52e531561230d65",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
|
|
@ -136,6 +208,24 @@
|
|||
"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"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
"uuid": "1116b838_7dbff72e",
|
||||
"filename": "specs/caracal/deferred_deletion.rst",
|
||||
"patchSetId": 6
|
||||
},
|
||||
"lineNbr": 55,
|
||||
"author": {
|
||||
"id": 32919
|
||||
},
|
||||
"writtenOn": "2024-01-22T05:40:08Z",
|
||||
"side": 1,
|
||||
"message": "3) Driver says it needs more time\n\u003e The main motivation is to make share allocation available immediately which was blocked on availability of quota and also not block the share manager call. Share manager asking periodically status where driver needs more time to delete or not seems bit overhead to me. \n1. driver now first calculate/decide whether it needs more time or not. \n2. Even if driver replies that no more time is needed, there is no guarantee that driver wont take more time.\n3. 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\nOn the other hand, the process we are following here is simple, where quota will be available immediately and background periodic task will handle cleanup.",
|
||||
"parentUuid": "252e837c_f7d3aeb2",
|
||||
"revId": "8521b194e420ef7de057ee72c52e531561230d65",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
}
|
||||
],
|
||||
"submitRequirementResults": [
|
||||
|
|
|
|||
Loading…
Reference in New Issue