New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support object store besides file store for persistancy in Weblate #2984
Comments
The problem is that we don't only need generic storage layer as django-storages is, but we rely on filesystem on which we can store working copies of the VCS repositories and files to execute external tools (eg. git, gettext). What could work here is focusing on Git only and storing the Git objects in a database and perform the operations on that or using temporary working copies. This not something we can do in forseable future. The other part is fulltext index, which will be gone in the 4.0 release, see #2825. For user uploaded content, it might be possible to use django-storages. It would certainly work for screenshots, but with fonts it would be again tricky, because the the rendering backend supports only loading fonts from a local directory. There seems to be a solution in C to load fonts directly, but that doesn't work out of box in Python as it touches too low level parts which are not exposed in the Python bindings. TLDR: It's probably not impossible, but would need major rewrite and it's certainly not on roadmap for now. |
- The code is now shared for repo and component level locking - It prefers Redis based locking as that usually performs better - The Redis locks will also nicely work in a distributed environment (WeblateOrg#2984)
- The code is now shared for repo and component level locking - It prefers Redis based locking as that usually performs better - The Redis locks will also nicely work in a distributed environment (#2984)
The beat file is problematic and it is better to have it in the database for distributed environments. This removes one dependency on shared filesystem, see WeblateOrg#732 and WeblateOrg#2984.
This setting was already used in Docker, now it is extended to general. See WeblateOrg#2984
The beat file is problematic and it is better to have it in the database for distributed environments. This removes one dependency on shared filesystem, see WeblateOrg#732 and WeblateOrg#2984.
Summary of what we store in the DATA_DIR and possible solutions:
Other affected features of storage change:
|
This setting was already used in Docker, now it is extended to general. See #2984
The beat file is problematic and it is better to have it in the database for distributed environments. This removes one dependency on shared filesystem, see WeblateOrg#732 and WeblateOrg#2984.
The beat file is problematic and it is better to have it in the database for distributed environments. This removes one dependency on shared filesystem, see WeblateOrg#732 and WeblateOrg#2984.
The beat file is problematic and it is better to have it in the database for distributed environments. This removes one dependency on shared filesystem, see WeblateOrg#732 and WeblateOrg#2984.
The beat file is problematic and it is better to have it in the database for distributed environments. This removes one dependency on shared filesystem, see WeblateOrg#732 and WeblateOrg#2984.
In order to separate application layer from persistancy layer in Openshift, the persistant volume clame in Openshift should not be used (files store). Instead, an object store as AWS S3 should be used, as django-storages would allow.
Question: is Weblate already supporting this today?
The text was updated successfully, but these errors were encountered: