[UI] Deactivate the delete button in the WebUI

[mctigger]

Hello,
I have a simple request: Deactivate the delete button in the WebUI!

In my opinion it does not make sense to be able to "delete" a task/artifact/dataset and then get a notification about artifacts not being deleted. It is hard to find the leftover files to delete later. Instead I suggest to disable deletion via the WebUI or add another step so that the user has to confirn he is sure to delete.

Although this does not solve the consistency issue that is currently inherent to ClearML, I think it is a sensible step to take until such operation are included into the API Server (at least that is what I understood from conversation from the Slack channel).

[ainoam]

@mctigger Let's try to break it down:

1. Remaining artifacts: The notification also lists all remaining artifacts, which comes to serve your comment on "hard to find the leftover files to delete later". Once the task is deleted, there is no context on which to save this information for future reference and so it is provided as part of the same flow (so you can copy that list use it to manually finish the cleanup as desired) - Do you see a more useful method?

2. Delete action safety: ClearML currently only lets you delete tasks that are already archived. In a sense, this is somewhat equivalent to an "Are you sure" message, as you still need two actions to really delete a task (First archive then delete).
   Since artifacts are deleted only once the delete action is carried out, I'm not sure adding an extra confirmation will help for the purpose of identifying leftovers. WDYT?

3. Removing delete action: Artifacts are kept when the artifacts are stored out of ClearML's reach (or due to an unexpected error). Where the ClearML file server is used, under normal circumstances - All artifacts are deleted: Wouldn't it make sense to retain the 'Delete' action for this common flow (keeping in mind that for other flows, point 1 above provide a resolution)?

BTW, extending the ClearML Backend to help removing artifacts from more locations is indeed coming in a near release, but I would think that this would reduce the cases of "left behind" artifacts, rather than make the scenario completely obsolete.

[mctigger]

Hi @ainoam thank you for replying so quick! I should have been more precise in why I think my proposal makes sense.

1. You are right, but you are looking it at from a "smart user" perspective. But I think it is better to always assume the worst possible user, which in this case would be one that just deletes tasks and does not care about the files until an admin says: "our disks are full for some reason, ClearML will be down for some time". Better be safe than sorry and disable deletion alltogether, so the cleanup script or an admin can handle deletion. Less good, but kinda "okay" would be to at least let clearml-server log all the file that have not been deleted. But I am strongly in favor of disabling and letting the cleanup script do the work instead of doing it manually.
2. I hope for a confirmation of this type: "If you delete this tasks, the following files will be leftover. Do you really want to delete tihe task?" File deletion is mainly missing due to missing front-end support, so it should be easy to check for which kind of file clearml can delete.
3. It seems like currently only the default config works with the WebUI. I was for example not able to get the WebUI to delete from a second clearml-fileserver. But this could be also a configuration problem on my side. So for every backend where the frontend is able to delete, I would support keeping the delete button.

[ainoam]

@mctigger The flip side is that there's a significant user base that actually needs task deletion, so it's a balancing act for usability...

File deletion is mainly missing due to missing front-end support

The real issue here is browser CORS limitations which restrict what front-end can do. That's why you can't have one installation delete files on another's file-server, and why the way to handle external artifacts would be through a back-end service.

Better be safe than sorry and disable deletion alltogether

Is "deletion" here task deletion, or specifically attached-file deletion while deleting tasks?
Are you trying to safeguard against accidental deletion or remove annoying output?

[mctigger]

The main issue I want to avoid is lingering files on the fileservers/S3/...
A way to avoid is to wait for confirmation of file deletion before deleting the task/dataset/artifact that references that file. If the user wants to delete anyways (so with notice of failed file deletion) he should confirm this.

[idantene]

Would be nice if the WebUI could simply delete the files from S3 as it's given credentials in the configuration 😅

[ainoam]

@idantene Indeed, though having the credentials is not enough due to browser CORS restrictions.