Admin housekeeping: delete containers in weblate gitlab.com forks of virtualization projects to save storage quota #8189
Comments
berrange
added
the
question
|
This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger. In case your question is already answered, making a donation is the right way to say thank you! |
That has now happened, the 'weblate' account has no remaining CI quota for the rest of October, having consumed its 2000 free minutes. |
|
I've done some cleanup of the storage now and that should be fine. I don't see a good solution for CI quota right now. The fix will be to have a proper integration with GitLab and stop using user for the integration... |
|
This issue has been automatically marked as stale because there wasn’t any recent activity. It will be closed soon if no further action occurs. Thank you for your contributions! |
Describe the issue
This is NOT a bug report, rather it is an administrative house keeping request/suggestion wrt weblate's usage of gitlab.com for various projects, that requires attention from weblate admins.
GitLab previously announced their intention to apply limits to the free tier
https://about.gitlab.com/blog/2022/03/24/efficient-free-tier/
https://about.gitlab.com/pricing/faq-efficient-free-tier/
The biggest way this will affect users of gitlab.com is through capping the available CI minutes, and through limiting storage usage. I don't know if weblate is using a free account or a paid subscription for gitlab.com, but either way weblate's account will be subject to CI and storage limits at some level. CI is already enforced, but storage enforcement is still not active, pending some accounting fixes in gitlab code.
If CI quota is exceeded, pipelines triggered by weblate would not be able to complete. That's not the end of the world. It just means project owners will have to trigger the pipeline themselves in the merge requests, such that they run with upstream's CI quota instead. In the storage case though, if that quota is exceeded, weblate's account would be entirely blocked until storage usage is reduced. Thankfully this isn't enforced yet, but it is only a matter of time.
I am maintainer for a number of virtualization related projects hosted on gitlab.com, which use Fedora Weblate instance to manage translations. Our projects have historically used a CI process which was very expensive on both CI minutes and storage usage for docker containers. Every fork that weblate has made will contain many GBs of containers. I have now updated our CI approach so that it will never result in creation of containers in forks, however, as upstream project owners we have no way to purge previously containers in each contributor's fork.
I am thus suggesting that weblate admins need to purge these containers to reduce their storage usage.
The following projects:
Correspond to the following gitlab.com repository container registries:
I'm not able to see usage under the weblate account, but I expect this quite possibly sums to 100's of GBs of containers. See the container registry usage figure shown under weblate's account at:
Anyway, as owner of the above projects, I'm suggesting weblate admins delete all containers present in the registries listed above, since their CI process no longer needs them to exist.
It would also be wise to look at storage usage across all other weblate fork'd projects to see if any others are likely to cause weblate to exceed it gitlab.com quota.
I already tried
Steps to reproduce the behavior
Expected behavior
No response
Screenshots
No response
Exception traceback
No response
How do you run Weblate?
weblate.org service
Weblate versions
No response
Weblate deploy checks
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: