2020-05-29 09:04 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006361BuildbotBuildbotpublic2020-05-14 13:32
Reporterabma 
Assigned Toabma 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusassignedResolutionopen 
Summary0006361: keep the last n builds
Descriptionatm builds are deleted by age, they should be deleted by age and the last n builds for the branch develop and maintenance should be kept.

https://github.com/Spring-Chobby/Chobby/issues/498#issuecomment-576298166
TagsNo tags attached.
Attached Files

-Relationships
related to 0006394new Spring engine get rid of 32 bit engine builds 
+Relationships

-Notes

~0020378

ThinkSome (reporter)

1. Are the windows x64 and linux x32 builds really necessary? Nobody seems to be using those, so keeping them around on expensive disks (servers) seems silly. Who uses the portables?

2. Ditto for the 120 MB win x32 debug packages. Store them home, on inexpensive storage and upload on request.

3. Scaleway offers 75GB per month of free object storage. That can store roughly 2500 version of lin64 and win32 builds (with some caching on frontend server).

4. How much (free) space does springrts.com server actually have?

~0020379

ThinkSome (reporter)

Behold, the tutorial: https://www.scaleway.com/en/docs/setting-up-object-proxy-object-storage/

~0020380

ThinkSome (reporter)

Ah, I see all builds have debug packages. Damn, 600 MB per version is a lot.

How much space is taken by all the maps @ springfiles? My server is also getting clogged by maps (2.5GB) and other stuff, so I was thinking of putting them all into object storage, anyway.

~0020381

abma (administrator)

proxy the request to an object storage would double the traffic...


all maps on springfiles.com are ~50GB

IMHO your idea doesn't solve the problem: the real problem is, that we need a "stable" release. we can't store builds forever, so a cleanup is required: with or without object storage.

~0020382

abma (administrator)

free disk space on springrts.com is currently ~100GB: thats mostly because very few new builds are created.

so a maybe a more advanced algorithm would take the available disk space into account: i.e. delete builds if few disk space is available and at least n builds are available.

~0020383

ThinkSome (reporter)

It would double the traffic for builds that have to be taken from object storage, but since the front-end would do caching, that would be a very rare event (assuming large enough cache ~ 1 GB).

Builds absolutely *can* be stored forever, the questions are only: where they are stored, which parts of these are stored and if doing so is rational. 2-Duplicated home storage here is 1 eur per 100GB per year in hardware, and anywhere from 1 to 15 eur in electricity. object storage is $12 per 100GB per year. Server bulk storage HDD space is probably much more expensive.

Just moving the 120MB debug packages to home storage would go a long way, without having to delete anything on the server! 1474*(15MB linux64+15MB windows32) = 44 GB
+Notes

-Issue History
Date Modified Username Field Change
2020-01-20 15:29 abma New Issue
2020-01-20 15:29 abma Assigned To => abma
2020-01-20 15:29 abma Status new => assigned
2020-03-26 22:40 abma Project Spring engine => Buildbot
2020-04-07 04:21 ThinkSome Note Added: 0020378
2020-04-07 13:33 ThinkSome Note Added: 0020379
2020-04-07 14:01 ThinkSome Note Added: 0020380
2020-04-07 22:22 abma Note Added: 0020381
2020-04-07 22:24 abma Note Added: 0020382
2020-04-07 23:18 ThinkSome Note Added: 0020383
2020-05-14 13:32 abma Relationship added related to 0006394
+Issue History