cvat
cvat copied to clipboard
Support on django-storages
Actions before raising this issue
- [X] I searched the existing issues and did not find anything similar.
- [X] I read/searched the docs
Is your feature request related to a problem? Please describe.
I'm working in an air-gapped network that I've managed to build CVAT inside, and a massive problem prevents me from using the system properly. The entire CVAT application is based on the server storage, which has to be shared with all its workers (i.e., importer, exporter, etc.). The solution proposed was a mount of the same directory to each container (in case of using docker-compose
) or using the same PersistentVolumeClaim
in case of using k8s.
As our usage of CVAT is for multiple clients in the organization, we decided to use k8s to run the app instead of a single VM that runs all with docker-compose. The problem starts when there are restrictions in our organization that prevent us from doing 2 key features:
- Attach the same claim to multiple pods.
- Mounting a Cloud Storage as a file system (such as
s3fs
) - as mentioned in the documentation.
Therefore it is impossible to serve CVAT in such an environment.
Describe the solution you'd like
There's a feature since Django 4.2
which now supports on storages. This feature can be used to manage (most of) the files used by CVAT, even just those that need to be shared across containers.
With no additional configuration, the application is supposed to run as usual since the default behavior would be "write the file to the same destination as they were supposed to be written". But when including the django-storages plugin, the storage destination doesn't have to be a file-system, and it can be a cloud-storages.
Describe alternatives you've considered
We first tried to use NFS to mount all the pods to the same endpoint, but in the end, as the storage capacity went up, so did the accessing time until it just crashed from so many timeouts.
When we used a very old version of CVAT, a big change to the code was made to create some kind of "bridge" between the file system and our cloud storage provider. This was a such good solution but it is now too big to create again and maintain it through future releases.
Additional context
No response