BTW, deleting using the SDK ( Task.delete() should handle all cases)
What do you mean by "disable deletion of artifacts"?
And how to specify this fileserver as output_uri ?
I guess the supported storage mediums (e.g. S3, ceph, etc...) dont have this issue, right?
I'll ask them. but I'm not sure regarding priority 😞
(and in the SaaS Hosted version as well, of course)
Yea, when the server handles the deletes everythings fine and imo, that is how it should always have been.
I don't think it is a viable option. You are looking at the best case, but I think you should expect the worst from the users 🙂 Also I would rather know there is a problem and have some clutter than to hide it and never be able to fix it because I cannot identify which artifacts are still in use without spending a lot of time comparing artifact IDs.
Can you give me an example how I can add a second fileserver?
The security scheme is indeed covered in the enterprise version
And how do I specify this in the output_uri ? The default file server is specified by passing True . How would I specify to use the second?
Any idea why deletion of artifacts on my second fileserver does not work?
fileserver_datasets: networks: - backend - frontend command: - fileserver container_name: clearml-fileserver-datasets image: allegroai/clearml:latest restart: unless-stopped volumes: - /opt/clearml/logs:/var/log/clearml - /opt/clearml/data/fileserver-datasets:/mnt/fileserver - /opt/clearml/config:/opt/clearml/config ports: - "8082:8081"
ClearML successfully stores artifacts on there, I can download them, but when I try to delete I get .... not deleted as error message, but 100% deletion and they get removed from the webserver, but remain on disk.
Well, you can simply duplicate the fileserver's docker-compose entry and expose it using a different port (8082 for example?)
I fully understand, the thing is it's not the server deleting the files right now, but the UI - once we add this option in the server, we will be able to provide this flow. Still, I'm sure that it would still be a viable option to delete a task even if the associated artifacts can't be deleted for some reason (for example, what if you have an artifact weighing a few KBs that's somehow corrupted?)
Should work since that's done by the SDK
Perfect and thank you for your efforts! :)
If there are models used by other tasks, they will be kept there under the existing structure
Btw: Is it intented that the folder structures in the fileserver directories is not deleted?
Ah, okay, that's weird 🙂 Thank you for answering!
I guess that's because the UI doesn't recognize it as a fileserver and does not attempt to send the requests there
Btw: It is weird that the fileservers are directly exposed, so no authentication through the webserver is needed. Is this something that is different in the paid version or why is it like that in the open-source version?
One thing I want to add: Maybe you disabling deletion of artifacts if file-server deletion fails. Doesn't make sense that we cannot track existing files if something goes wrong.
Ah, I see. Any way to make the UI recognize it as a file server?
In these mediums, the UI currently does not handle deleting
Ah, thanks a lot. So for example the CleanUp Service ( https://github.com/allegroai/clearml/blob/master/examples/services/cleanup/cleanup_service.py ) should have no troubles deleting the artifacts.
Hi SuccessfulKoala55
I meant that in the WebUI deletion should only be allowed for artifacts for which deletion actually works.
For example I now have a lot of lingering artifacts that exist on the fileservers, but not on the clearml-api-server (I think).
Another example: I delete a task via WebUI. ClearML-server tries to delete the task and the artifacts belonging to the task. However, it will show that the task has been successfully deleted but some artifacts have not. Now there is no way anymore to delete the artifacts except for asking the admin to manually look for files on the fileserver.
In my opinion the task should only be deleted after the artifacts have been deleted successfully . And the artifacts should only be deleted from the server when the fileserver successfully deletes the files behind the artifacts.
Well, it's certainly in our workplan 🙂
Just use the full URL for the server (i.e. http://<server-address>:8082 )