Skip to content
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

Open
rhofer opened this issue Aug 29, 2019 · 2 comments
Open

Support object store besides file store for persistancy in Weblate #2984

rhofer opened this issue Aug 29, 2019 · 2 comments
Labels
enhancement Adding or requesting a new feature. undecided These features might not be implemented. Can be prioritized by sponsorship.

Comments

@rhofer
Copy link
Contributor

rhofer commented Aug 29, 2019

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?

@nijel
Copy link
Member

nijel commented Aug 29, 2019

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.

@nijel nijel added enhancement Adding or requesting a new feature. undecided These features might not be implemented. Can be prioritized by sponsorship. labels Aug 29, 2019
nijel added a commit to nijel/weblate that referenced this issue Apr 14, 2021
- 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)
nijel added a commit that referenced this issue Apr 14, 2021
- 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)
nijel added a commit to nijel/weblate that referenced this issue Jan 19, 2023
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.
nijel added a commit to nijel/weblate that referenced this issue Jan 19, 2023
This setting was already used in Docker, now it is extended to
general.

See WeblateOrg#2984
nijel added a commit to nijel/weblate that referenced this issue Jan 19, 2023
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.
@nijel
Copy link
Member

nijel commented Jan 19, 2023

Summary of what we store in the DATA_DIR and possible solutions:

  • avatar-cache - this does not need to persist, can be rebuilt, not all workers need it
  • backups - needed on the backup worker only for doing backups
  • cache - fontconfig local cache, this really should live inside /app/cache in the Docker, will be fixed in utils: Allow to define cache directory separately #8636
  • celery - celery beats schedule, should be addressed by celery: Use django-celery-beat for storing schedule #8635
  • fonts - fonts used by fontconfig/pango/cairo, these need to be on the actual filesystem and kept in sync
  • home, ssh - configuration for command line tools invoked by Weblate, some files can be regenerated, but some need to persist (SSH keys, borg backup keys)
  • media - user uploaded screenshots, this one should be ready for using other storage
  • projectbackups - these should be possible to rewrite using Django storage layer
  • static - is already using /app/cache in Docker
  • vcs - version control data, right now Weblate supports Git, Mercurial and git-svn, so solution for both is needed, for Git https://github.com/bgahagan/git-remote-s3 might be a solution

Other affected features of storage change:

  • Backups rely on having all repos in DATA_DIR, so doing full backup will need full repo sync as well

nijel added a commit that referenced this issue Jan 19, 2023
This setting was already used in Docker, now it is extended to
general.

See #2984
nijel added a commit to nijel/weblate that referenced this issue Jan 26, 2023
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.
nijel added a commit to nijel/weblate that referenced this issue Jan 26, 2023
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.
nijel added a commit to nijel/weblate that referenced this issue Jan 26, 2023
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.
nijel added a commit to nijel/weblate that referenced this issue Jan 26, 2023
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.
nijel added a commit that referenced this issue Jan 26, 2023
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 #732 and #2984.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adding or requesting a new feature. undecided These features might not be implemented. Can be prioritized by sponsorship.
Projects
None yet
Development

No branches or pull requests

2 participants