)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"edb081dceb163e83b6676bfd931abe9bd95525c2","unresolved":true,"context_lines":[{"line_number":12,"context_line":"3600 seconds and add an option `netapp_unmount_share_timeout`"},{"line_number":13,"context_line":"that enables the administrator to set it accordingly."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Closes-Bug: #1960239"},{"line_number":16,"context_line":"Change-Id: I9370f944aeeeda354e7df5f3f22310c2a9be3b94"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"233f5c2b_9a643986","line":15,"range":{"start_line":15,"start_character":12,"end_line":15,"end_character":20},"updated":"2022-06-21 18:48:49.000000000","message":"Felipe, were either of the suggestions by Maurice considered? I\u0027m not a big fan of long timeouts and waits since the driver will be wasting a share manager thread waiting. If we\u0027re now able to detect a clone split; couldn\u0027t we just abort it and delete the new volume?","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"},{"author":{"_account_id":31721,"name":"Felipe Rodrigues","email":"felipefuty01@gmail.com","username":"felipefutty"},"change_message_id":"f1c43cb52ee00935629278dad2cbd31dbd0c1ab2","unresolved":true,"context_lines":[{"line_number":12,"context_line":"3600 seconds and add an option `netapp_unmount_share_timeout`"},{"line_number":13,"context_line":"that enables the administrator to set it accordingly."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Closes-Bug: #1960239"},{"line_number":16,"context_line":"Change-Id: I9370f944aeeeda354e7df5f3f22310c2a9be3b94"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"11ccc433_2b9e118e","line":15,"range":{"start_line":15,"start_character":12,"end_line":15,"end_character":20},"in_reply_to":"08d41ddb_2eebbe21","updated":"2022-06-22 13:07:09.000000000","message":"What do you mean by deferred deletions ?! A kind of soft delete only using the driver (like NetApp snapshot deletion does) ?! If so, there are some drawbacks:\n\n1. Manila will be unsynchronized with the storage for a period of time, since the driver will report that the share was deleted, but it will try to delete later. The scheduler might have some period of time with wrong information.\n\n2. Increases the complexity of the driver code --\u003e harder to maintain the code and easier for come up with some bugs\n\n3. Confuses operators: they might not understand why we haven\u0027t deleted the share on storage and reported by Manila as deleted (for those that did not follow the discussion).\n\nIt sounds more like a workaround on driver side to overcome a \"wrong\" Manila design.\n\n\nFrom my point of view, the Manila is not designed for that. Manila delete operation works as single share manager thread, the driver must be able to delete or fail the deletion in a single manager request. This behavior could be changed, adding the possibility for drivers to start the deletion and then having a periodic task that asks drivers about the status of that operation. Actually, we could do it for creation too. Like\n\n1. Manila API sets the status of share to \"creating\" or \"deleting\"\n1. Share Manager ask driver to create/delete a share\n2. Driver answer starts the operation on storage. Returns to manager to a new status \"creating_on_storage\" or \"deleting_on_storage\".\n3. A periodic task retrieves from db the shares with those status and send to a driver interface like \"update_storage_operation\". The driver checks for each share the status fo the operation and returns the update for the manager.\n\n\nThat way the long time operation is controlled by the manager, not by a driver workaround. From operators perspective, they only will see the share disappeared from the \"manila list\" when the share has been created/deleted totally.\n\nWdyt ?!","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"f408133c2a1ab881d179643bbdbc4b898c9e9c55","unresolved":true,"context_lines":[{"line_number":12,"context_line":"3600 seconds and add an option `netapp_unmount_share_timeout`"},{"line_number":13,"context_line":"that enables the administrator to set it accordingly."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Closes-Bug: #1960239"},{"line_number":16,"context_line":"Change-Id: I9370f944aeeeda354e7df5f3f22310c2a9be3b94"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"c256abd5_c5e20db2","line":15,"range":{"start_line":15,"start_character":12,"end_line":15,"end_character":20},"in_reply_to":"11ccc433_2b9e118e","updated":"2022-06-22 13:48:24.000000000","message":"That\u0027s what i was going for with deferred deletion. We could use a \"micro\" state like you\u0027re suggesting \"deleting-on-storage\" or something like that (translate that to \"deleting\" via the API; user doesn\u0027t need to know the internal details); and tag this onto the share manager periodic task to check with the driver about the deletion","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"},{"author":{"_account_id":31721,"name":"Felipe Rodrigues","email":"felipefuty01@gmail.com","username":"felipefutty"},"change_message_id":"aeb2e286d554cd54a9f83979f8dee2112e567959","unresolved":true,"context_lines":[{"line_number":12,"context_line":"3600 seconds and add an option `netapp_unmount_share_timeout`"},{"line_number":13,"context_line":"that enables the administrator to set it accordingly."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Closes-Bug: #1960239"},{"line_number":16,"context_line":"Change-Id: I9370f944aeeeda354e7df5f3f22310c2a9be3b94"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"506598ed_2a51e7cb","line":15,"range":{"start_line":15,"start_character":12,"end_line":15,"end_character":20},"in_reply_to":"233f5c2b_9a643986","updated":"2022-06-21 19:00:08.000000000","message":"For sure, I tried the Maurice\u0027s idea of stopping the clone split, it did not work. At least on my environment, If I run the stop after running the split, it fails [1]. Right after start the split, the volume field \"clone\" becomes \"False\" and we can not run the split stop.\n\n\n\n[1] https://paste.opendev.org/show/bH0CyBi8JYBpaW56CWGn/","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"af319e48ba2e126da17b301c33bc0f8c98c5b968","unresolved":true,"context_lines":[{"line_number":12,"context_line":"3600 seconds and add an option `netapp_unmount_share_timeout`"},{"line_number":13,"context_line":"that enables the administrator to set it accordingly."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Closes-Bug: #1960239"},{"line_number":16,"context_line":"Change-Id: I9370f944aeeeda354e7df5f3f22310c2a9be3b94"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"08d41ddb_2eebbe21","line":15,"range":{"start_line":15,"start_character":12,"end_line":15,"end_character":20},"in_reply_to":"506598ed_2a51e7cb","updated":"2022-06-22 11:02:54.000000000","message":"ugh, so ONTAP\u0027s lying about the status because its tracking the splitting elsewhere. The best solution here would be deferred deletions; is that too hard to implement?","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"},{"author":{"_account_id":18816,"name":"Maurice Escher","display_name":"carthaca","email":"maurice.escher@sap.com","username":"mapocace"},"change_message_id":"b4c3bdc02302cda0f8ad4c9f703f65536c8c7d96","unresolved":true,"context_lines":[{"line_number":12,"context_line":"3600 seconds and add an option `netapp_unmount_share_timeout`"},{"line_number":13,"context_line":"that enables the administrator to set it accordingly."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Closes-Bug: #1960239"},{"line_number":16,"context_line":"Change-Id: I9370f944aeeeda354e7df5f3f22310c2a9be3b94"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"a71f6be4_bc1df0d5","line":15,"range":{"start_line":15,"start_character":12,"end_line":15,"end_character":20},"in_reply_to":"c256abd5_c5e20db2","updated":"2022-11-25 15:45:08.000000000","message":"I would like it better, if such shares that are \u0027deleting-on-storage\u0027 are hidden from the users.\nNo need to show internals, that some shares are deleted immediately and some are not.\n\nAnd most importantly my users want to get back the quota to create new shares early.","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":31721,"name":"Felipe Rodrigues","email":"felipefuty01@gmail.com","username":"felipefutty"},"change_message_id":"aeb2e286d554cd54a9f83979f8dee2112e567959","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"493283cb_48f2eaa4","updated":"2022-06-21 19:00:08.000000000","message":"Thanks Goutham, please, see my reply.","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"3ec531ee348d35758159fd0389c6308c26982df2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"51f27c85_4262ee4f","updated":"2024-03-27 21:30:48.000000000","message":"Thanks Maurice!","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"},{"author":{"_account_id":35677,"name":"Thiago José de Andrade Alvoravel","display_name":"Thiago Alvoravel","email":"thiago.andrade@fit-tecnologia.org.br","username":"thiagoalvoravel"},"change_message_id":"be688f8d5aa6a28415e71212c3adc7d901b6feea","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3e505141_587d0038","updated":"2023-03-01 18:24:54.000000000","message":"Thanks for this patch. I am thinking it would be good have Zuul and NetApp CIs building successfully for garantee that high default `netapp_unmount_share_timeout` value won\u0027t cause any timout/errors in other operations. That makes sense to you?","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"},{"author":{"_account_id":18816,"name":"Maurice Escher","display_name":"carthaca","email":"maurice.escher@sap.com","username":"mapocace"},"change_message_id":"b440e5cfef30a008d9c8c71b3a0964615ed54170","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4c735ef3_e0e0b0b7","updated":"2024-03-27 12:38:58.000000000","message":"This can most likely be abandoned, since https://review.opendev.org/c/openstack/manila/+/888927 addresses the issue in a different way.","commit_id":"e8504cd2ae3413a5584572b602cba8d1c4e26697"}]}