GitLab gaat toch geen inactieve projecten verwijderen

GitLab heeft zijn beslissing om vanaf eind september inactieve projecten te verwijderen teruggedraaid. De ongebruikte repository's gaan naar goedkopere object storage, waardoor ze nog toegankelijk zullen zijn, maar read times op de servers wel langer worden.

GitLab wilde met de plannen een miljoen dollar per jaar aan hostingkosten besparen en meldt zelf de koerswijziging. Wat de definitie van 'inactief' is in deze context, weet GitLab zelf ook nog niet. "Waarschijnlijk zouden alle schrijfoperaties een project actief houden. Een issue opzetten, een merge request, veranderingen naar een branch pushen, et cetera", licht de Nederlandse GitLab-medeoprichter en ceo Sid Sijbrandij toe.

De gewijzigde plannen zijn volgens The Register nog niet heel concreet, omdat het plan voor verwijdering er al langer zou liggen. Eind juli was de code om projecten automatisch te verwijderen klaar, 'na maanden van debat en ontwikkeling'. De koerswijziging komt volgens bronnen van The Register door de 'woede die geuit werd op Twitter en Reddit'. Ook in de reacties onder het Tweakers-nieuwsartikel over dit onderwerp waren mensen overwegend negatief over de strategie.

GitLab is een DevOps-platform dat wordt gezien als een belangrijke concurrent voor repositoryplatform GitHub. GitHub werd tot ongenoegen van veel gebruikers in 2018 overgenomen door Microsoft. GitLab is de enige grote zelfstandige speler in de repositorymarkt, omdat Bitbucket is overgenomen door Atlassian.

Reacties (54)

[shades]

Gitlab-ce lokaal hosten en je voorkomt dit soort ellende. Ik draai het nu inmiddels een jaar of twee thuis (kant en klare docker - en draait binnen unraid nu maar docker is docker). Gitlab-ce kan je ook op werk draaien. Tevens ieder moment een backup kunnen draaien van al je projecten.

[RoestVrijStaal]

GitLab is geen licht pakket.

4GB+ aan RAM en 4+ cores aan CPU.

Dan kun je beter Gitea nemen: 2 CPU cores en 1GB RAM

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 00:16]

[Gehenna]

Gitlab 'supports up to 500 users' met die specs, Gitea is 'typically sufficient for small teams/projects' met die specs. Hoe groot zo'n klein team is wordt niet aangegeven. Dus wellicht zijn beide gegevens niet 1 op 1 met elkaar te vergelijken.

[shades]

Inderdaad. Wij gebruiken gitlab-ce ook op het werk met een handje vol mensen en die spec die roestvrijstaal daar opgeeft heb je bij lange na niet nodig. Tevens.. als je al gitlab-ce naar tevredenheid hebt draaien ga je niet spontaan iets anders neerzetten.

[Loggedinasroot]

Inderdaad. Zelfs met workers en de nodige extras.

[Oon]

Het is inderdaad niet zo dat Gitea en GitLab dat soort specs nodig hebben voor precies hetzelfde, maar toch heeft GitLab een hele boel features ingebakken en is het opgezet als een groot softwarepakket, terwijl Gitea gewoon goed is in één ding.

Ik draai bijv. op mijn werklaptop een Gitea instance in docker omdat ik die UI soms wel handig vind voor diffs en om gewoon te zien wat er gaande is in verschillende repo's, maar met GitLab zou dat gewoon niet gaan zonder mijn laptop nagenoeg onbruikbaar te maken. Ik heb alle extra dingen waar GitLab resources aan besteedt in dat geval ook niet nodig.

Thuis heb ik een GitLab omgeving draaien met CI om automatisch docker images te builden enzo, en daar heb ik dan weer weinig aan Gitea omdat het mij vooral om de CI en Docker registry gaat.

[gimbal]

En laten we eerlijk zijn... Gitlab is goed in veel dingen maar de diff view in de UI is best wel moeilijk om te lezen. Ik gebruik er zelf mijn IDE voor zelfs al moet ik een review doen.

[Stry]

Je kan hem als side-by-side instellen. Verbetert die view al heel veel.

[bazzi]

Helaas niet genoeg.zeker bij ingewikkelde merge conflicten, of grote diffs. Ja beter beide voorkomen, maar ja toch heb je het soms. Dan is gitlens in vscode een uitkomst.

[THA_ErAsEr]

"Recommended" voor "up to 500 users"
Als je het enkel voor jezelf draait, maakt het mogelijk niet uit of het lichtsnel gaat of niet.

[Tadango]

Bedankt, gitlab vraagt op mijn docker host ook redelijk veel resources. Ik zal gitea eens bekijken of dat werk voor mijn configuratie.

[Hydranet]

Ik ben sinds gisteren ook over op mijn eigen gehost Gitea, vrij simpel op te zetten en licht. En voor privé repos gebruiken de meeste mensen toch niet al die extra devops dingen die er bij Gitlab in zitten.

[Tadango]

Nee ik ook niet, maar wel CI/CD edg. Dat schijnt via Drone te kunnen. Komende winter eens induiken.....

[jvwou123]

k heb een VPS'je met alles in docker. Onder andere: gitea en Jenkins en harbor. Als ik in de juiste org een nieuw project maak wordt ie automatisch mee genomen in Jenkins. Daarna maakt ie docker containers, en mijn self-hosted docker registry

Het is wat gepuzzel en zo. maar alles draait nu wel compleet self-hosted. Is het nuttig? geen idee, maar het is wel leuk met te klooien.

[Sandor_Clegane]

Ach het neemt wat memory in beslag. Gitea is ook mooi (geschreven in Go) maar miste wat functies die ik wel handig vond.

[haling]

Wij zijn ook precies om die reden overgestapt naar GItea. Niet alleen is Gitlab ontzettend zwaar, een restart duurt ook minuten en back-ups zijn nogal groot.

Wij zijn heel blij met Gitea; aanrader dus!

[CH4OS]

Ik heb wat kleine hobby projectjes op Gitlab staan. Ik zou dat best in de community edition kunnen plaatsen en zelf hosten, maar dan moet ik het ook 24/7 draaien. Daar zit ik simpelweg niet op te wachten voor twee kleine (en intussen ook overleden) hobby projectjes.

[bzuidgeest]

Dat is leuk voor jou, maar als je een project wil delen en een redelijke kans geven om "permanent" online te zijn dat is hosten bij een git-provider de enige echte optie.

Thuis servers komen en gaan, en alhoewel zoals je in dit artikel ziet, ook online natuurlijk aan verandering onderhevig kan zijn is het over het algemeen veel stabieler online. Geen abbo, geen kosten. En zelfs google code kun je nog steeds bij het archive en codeplex code is te vinden op archive.com

[Annihlator]

Lokaal hosten gebeurt niet enkel op thuisservers he
Zeker als je daarin verder kijkt is het al snel makkelijk te onderbouwen dat het betrouwbaarder of zelfs performanter kan zijn indien het een onsite situatie betreft

En er is een nadeel aan de oplossingen online zonder kosten; die zijn vaak publiekelijk inzichtelijk, zeker als je het bedrijfsmatig bekijkt zijn er al snel meer voordelen te vinden bij een self-hosted platform.

Voor energiekosten tussen 2 tot 3 accounts per maand kan je dit al redundant uitvoeren (aanschafkosten vd hardware echter niet meegenomen)

[Reactie gewijzigd door Annihlator op 23 juli 2024 00:16]

[McBacon]

Ik draai Gogs (precursor van Gitea) op een VPSje van een paar euro. Ik kan met htpasswd bepaalde public repos toch beveiligen, je hoeft dan niet per se een account te hebben of collaborator te zijn van die repos. Succes met zoiets te fixen op GitHub of hosted Gitlab. Als er een beetje kennis is van serverbeheer e.d. is het algemeen gezien denk ik altijd beter om lekker self-hosted te gebruiken. Ja het is misschien duurder om mee te beginnen, maar voordelen als heel makkelijk alle repos (met alle branches, issues, merge requests, ...), git- en webhooks, etc kunnen backuppen (en terugzetten) zijn ook aardig wat waard.

[bzuidgeest]

Ik denk niet dat de gitlab actie betaalde bedrijf repos betrof. Ik ging van pure gratis accounts uit en niet de bedrijfsmatige.

Het bedrijf waar ik werk host ook zelf omdat de code en techniek binnenhuis moet blijven. GitHub en gitlab hebben ook private repos did niet publiek zijn, maar onze code spreekt in de ci pipeline en tests dingen aan die we niet extern bereikbaar kunnen hebben. Dus intern moet dan.

[dasiro]

tja, maar dan moet je er ook bij nemen dat hosting geld kan kosten of nix gegarandeerd is.

[c-nan]

De ongebruikte repository's gaan naar goedkopere object storage, waardoor ze nog toegankelijk zullen zijn, maar dat simpelweg wat langer zal duren.

Wat zal langer duren?

En wat als je commentaar plaatst in een inactieve repo? Gaat deze dan weer terug?

Ik heb het idee dat dit alles alleen maar meer gaat kosten ipv iets opleveren.

[Reactie gewijzigd door c-nan op 23 juli 2024 00:16]

[nzall]

je kunt zeggen: projecten met minder dan X activiteiten door Y users per maand worden verplaatst.

[djwice]

Zo simpel is het helaas niet. De retrieval kosten van inactive infrequent storage zijn 2x zo hoog als van de standaard storage class.

Inactive Infrequent storage is met name bedoeld voor dingen die maar een paar keer per jaar of minder worden opgevraagd.
Anders is inactive infrequent storage juist duurder dan standaard storage.

GitLab zou kunnen overwegen om alles wat niet meer gewijzigd is in de afgelopen x maanden wel in de CDN cache te zetten met een cache-control setting, waarbij de stale-while-revalidate en stale-if-error op een paar jaar staan, ook moet wellicht gekeken worden naar de s-maxage.
Zie https://developer.mozilla...TTP/Headers/Cache-Control voor details.

Zolang er geen wijzigingen zijn, hoeft de storage niet aan de CDN te hangen (via rechten management alleen toegang tot active storage), die krijgt dan een error (404) en zal dan de al aanwezige content in de cache blijven serveren.

De CDN heeft geen storage kosten voorzover ik weet, wel een maximale bewaartijd van 365 dagen. Dus moet de infrequent storage minimaal 1x per 364 dagen toegankelijk zijn voor de CDN en de Function.
Dit gegeven betekent dat er een goede kosten overweging gemaakt moet worden. Kosten voor terug halen zijn ~€0,025 per 1.000 bestanden, tegen €0.005 voor standard class requests. Bij meer dan 6.000 bestanden per GB, wat heel normaal is voor Git, is het niet voordeliger om andere storage classes dan standard storage class te gebruiken.

Komt er toch weer een wijziging, dan zal het project weer naar active storage verhuizen en zal de CDN zichzelf bij het eerst volgende request updaten.

Via serverless Functions kunnen request worden gemaakt die vlak voor het verplaatsen naar een lagere storage class alle type requests uitvoert die een repo krijgt, zodat de response in de CDN cache wordt opgenomen.
De acties/requests van die functie moeten uitgesloten worden van de Object Lifecycle Management.
Dat kan door de Object Lifecycle Management regels te baseren op bestandswijzigen (PUT/POST/PATCH/UPDATE/DELETE) en niet op basis van requests.

[Reactie gewijzigd door djwice op 23 juli 2024 00:16]

[batjes]

Hoeft natuurlijk niet per sé inactieve storage te zijn.

Het kunnen ook gewoon de oude afgeschreven storage servers zijn. Die krijgen wat lagere prio op het interne netwerk, worden niet zo vaak meegenomen in de backups.

Je kan het prima scheiden naar goedkopere storage oplossingen en zo een hele bak geld besparen, terwijl je het wel beschikbaar houdt.

[djwice]

Je hebt gelijk, ik bedoelde inderdaad 'Infrequent' access.
Ik heb geen idee hoeveel stroom een aantal oude SAN-oplossing in diverse data centra combineren plus de extra netwerk componenten kosten. En of dat opweegt tegen de cloud opslag kosten (~€0.24 per GB per jaar voor active storage incl. 3 tot 9 replica's, voor 'Infrequent' is dat ~ €0,12).
____
Ik ga er inderdaad vanuit dat GitLab in de Twitter post met 'Object Storage' verwijst naar Google Object Storage.

Het hoeft natuurlijk niet met Google Cloud, het kan ook met AWS S3 (Object Storage) en AWS CloudFront (CDN) en S3 Policies (rechten) en Object Lifecycle Management. In combinatie met AWS Lambda Functies die requests kunnen uitvoeren (net zoals Google Function) gebaseerd op het lifecycle event en de cache-control header kan toevoegen aan bestanden op basis van update/put events.

En uiteraard kan in plaats van AWS of Google CDN ook CloudFlare gebruikt worden. Wellicht is zelfs de goedkoopste versie van CloudFlare goed genoeg als CDN functie in deze set-up.

Eventueel kunnen de CloudFlare serverless functions diverse Git functies faciliteren (op AWS kan dat met Lambda@Edge in de N. Virginia regio), maar dat is denk ik niet nodig.

____

Het voordeel van Cloud Object Storage is de multi zone opslag (verschillende duplicaten in meerdere data centra), een betrouwbaarheid met 11-negens, hoge uptime en hoge parallelle netwerk verbinding tot je storage.

Zo heb ik in de praktijk voorbeelden van ruim 8.000 concurrent requests op een net nieuw geupload bestand van 1 GB welke zonder problemen worden afgehandeld, ruim binnen een minuut zijn de ruim 8.000 servers klaar met het lezen en interpreteren van de data. Een gemiddelde snelheid van meer dan 133Gbps.
Terwijl alle andere lees en schrijf acties ook gewoon ongestoord door gaan.

Dat is met de AWS s3 standaard storage class zonder CDN. Voor een lagere storage class kan dat wellicht anders zijn.

___
Even kort uitgerekend stel je besteed 1 miljoen dollar per jaar aan opslagkosten (alleen) voor de goedkoopste versie van FireStore ($0.20 per GB per maand = ~ 400 TB) en je migreert dat naar Standard class Object Storage ($0.02 per GB per maand).
De besparing is dan:
$1.000.000/($0.20 - $0.02) = $900.000,-

Bij Google CDN betaal je voor cache fill per GB $0.01 en niet voor het leven van de cache.
Egress voor CDN is $0.01 per GB en voor Object Storage minimaal $0.03.
Dat betekent dat een CDN bovenop de Object Storage al goedkoper is als slechts de helft van de bestanden wordt opgevraagd voordat ze worden bijgewerkt. Dat lijkt me voor een Git-repo heel normaal. Dus in alle gevallen is het slim om CDN te combineren met Object Storage voor Git.

De FireStore egress kosten zijn gelijk aan de CDN egress kosten.
Dat betekent dat de CDN fill kosten additionele kosten zijn t.o.v. de huidige kosten, dus van de $900.000 besparing moeten worden afgetrokken (want het zijn extra kosten).

Dat betekent dat bij 75 petabytes aan GIT push data per maand (900PB per jaar) object storage met CDN niet meer goedkoper is.

Let wel dit dit alles op basis van list pricing. Ik ga er vanuit dat bij bovenstaande situatie het Google Account team zeker een flinke korting zal aanbieden.

____
Het is daarmee kosteneffectief om de tekstbestanden in een Git push (met content-encoding gzip) niet te decoderen, maar gewoon gzip gecomprimeerd te laten en op te slaan in de object storage en zo ook in CDN te laten landen. Zo zijn de opslag, fill en egress kosten lager.

[Reactie gewijzigd door djwice op 23 juli 2024 00:16]

[biteMark]

Heb je het artikel wel helemaal gelezen? Het staat er letterlijk in:

Wat de definitie van 'inactief' is in deze context, weet GitLab zelf ook nog niet. "Waarschijnlijk zouden alle schrijfoperaties een project actief houden. Een issue opzetten, een merge request, veranderingen naar een branch pushen, et cetera", [...]

Voor nu is dat dus nog onduidelijk. Afwachten dus.

[Archcry]

In dat stukje text staat dus precies niet wat @c-nan vraagt. Men weet nog niet wanneer een project als inactief gemarkeerd wordt. Dat is inderdaad onduidelijk. Wat @c-nan vraagt is of een project weer van inactief naar actief gaat als men een schrijfactie uitvoert. In het stuk text wordt alleen geproken over "actief houden" maar niet "opnieuw activeren". M.a.w. de vraag van @c-nan wordt niet beantwoord in het artikel en persoonlijk vraag ik mij ook af wat er gebeurt als je een comment plaatst op een inactief project.

[c-nan]

Ja, dat heb ik.

Heb jij mijn reactie helemaal gelezen en ook begrepen? In het artikel komt het antwoord namelijk niet naar voren.

[Xander2]

Ik vermoed dat uiteindelijk gratis accounts naar de goedkopere en tragere storage zullen gaan, dat is veel eenvoudiger te regelen en maakt een betaald account interessanter.

[supersnathan94]

Ik vermoed het niet. Retrieval costs in dergelijke tiers zijn veel hoger. Kosten voor gratis accounts die actief zijn zullen dan ook de pan uit vliegen.

Actief weer iets terugschrijven (zeg PR of branch push) is relatief duur en wil je niet drie keer per dag doen. Hoogstens 1x per maand oid. Op dit soort storage wil je echt alleen inactief read only spul neerzetten. Zodra er weer wat actiefs gedaan wordt zet je een kopie naar een hogere tier en die schrijf je dan na een maand weer eens een keer weg naar de lagere tier. Heb je ook gelijk een soort back-up.

[Xander2]

Ik ben niet zo op de hoogte van het aanbod, maar kan me voorstellen dat er aanbieders zijn in dezelfde tier als nu maar met minder IOPS, bandbreedte en locaties.

De oplossing die jij aanhaalt lijkt me dat je naast allocatie slechtste geval ook nog een flinke bulk netwerkverkeer en CPU tijd moet investeren en een groot deel on-demand.

[supersnathan94]

Daarom zet je dat dus niet ineens bij een andere aanbieder neer. Intern verkeer is vaak zo goed als gratis en high bandwidth (in aws met een beetje database heb je 25gbit/s beschikbaar).

De oplossing die jij aanhaalt lijkt me dat je naast allocatie slechtste geval ook nog een flinke bulk netwerkverkeer en CPU tijd moet investeren en een groot deel on-demand.

Ja en juist dat zorgt dus voor een kostenreductie doordat inactieve projecten maar mondjesmaat gemigreerd hoeven worden bij activiteit. Stel dat er na een jaar een update komt dan wordt er ws op een aantal weken een behoorlijke hoeveelheid commits gedaan, PR en merging. Als je dat niet op trage object storage hoeft te doen scheelt dat best veel kosten. Schrijven daarnaartoe is vaak duur doordat er shingled disks worden gebruikt en er soms dus enkele terabytes aan dat opnieuw moeten worden geschreven voor een wijziging van 1 byte.

[this]

De acties die je wilt doen met die repo zal wat trager gaan aangezien ze naar een goedkopere storage verhuisd worden.

[Christoxz]

Het laden.

We discussed internally what to do with inactive repositories.
We reached a decision to move unused repos to object storage.
Once implemented, they will still be accessible but take a bit longer to access after a long period of inactivity.

[Nimja]

Ik moet zeggen dat MS toch wel veel goede verbeteringen aan GitHub heeft doorgebracht. CI/CD, code scanning, browser-based VSCode en nog veel meer tools.

Alternatieven zijn altijd goed natuurlijk, maar GitLab sneed zichzelf hiermee zo in de vingers. Want dan zijn ze geen platform meer voor (long term) open source.

[Koen Hendriks]

@Nimja Letterlijk alle voorbeelden die je nu noemt als verbetering van GitHub zaten dus al jaren lang in Gitlab.

Microsoft heeft hier even goed afgekeken hoe het beter kan

[Reactie gewijzigd door Koen Hendriks op 23 juli 2024 00:16]

[bzuidgeest]

beter goed nagedaan dan niet gedaan.

[gimbal]

Gratis prive repos. Ik heb mijn projecten nu op Bitbucket cloud staan omdat het destijds de enige optie was om gratis je repos prive te houden. Niet dat ik er ontevreden mee ben overigens, werkt nog steeds erg goed.

[smesjz]

Gitlab maakt nog steeds veel verlies, 44m GAAP (https://www.globenewswire...22-Financial-Results.html) dus ik hoop dat ze nog verder kijken dan de besparing van 1 miljoen...

En slechte PR zo

[Memori]

Ze mogen van mij inactieve projecten wel verwijderen, maar een jaar is te kort. Maak er dan drie jaar van, en introduceer een goedkopere "supporter" abonnement (a la €15/jaar) waarvan de projecten niet verlopen.

Het goedkoopste abonnement nu is voor mij te duur. Niet dat ik €19 per maand niet kan betalen, maar 1) het is te veel om alleen Gitlab te ondersteunen als je geen gebruik maakt van de features, en 2) ik heb 7 gitlab accounts die ik allemaal gebruik, en dus niet 7x€19 per maand wil betalen terwijl ik wel 7x€15 per jaar zou doen.

Introduceer dus een supporter abonnement. Projecten blijven altijd. Vinkje bij de gebruikersnamen. Kan een goede inkomstenbron zijn.

[Reactie gewijzigd door Memori op 23 juli 2024 00:16]

[smesjz]

Als je 7 accounts hebt dan ben je ook hobby / persoonlijk gebruik voorbij. En waarom zou je gitlab sponsoren en niet het (open source) project zelf?

[mutley69]

Dat is heel fijn, maar de dreiging volstaat om het project toch met een scheef oog te bekijken - het is nog beter dan github in handen van diegenen die Linux ooit een kanker noemden, en nu door linux nog meer verdienen dan voorheen! Alles is relatief - maar ik ben beestig streng in mijn beoordelingen van bedrijven. Geen enkel, maar dan ook geen enkel bedrijf verdient u als fan. Wantrouwen is de start van alles.

[gimbal]

Gezonde terughoudendheid zou ik eerder voor gaan.

[divvid]

Prima oplossing om inactieve projecten naar een goedkopere storage te pushen. Doen we intern ook met oude data.

‘t is net als met de zolder. Zodra je dat nutteloze ding dat al 5 jaar ligt te verstoffen weg hebt gegooid, heb je het nodig..*

*CF kaart lezerje b.v, grrrrr

[Reactie gewijzigd door divvid op 23 juli 2024 00:16]

[Dracster]

Gebruik Gitea nu ook al een tijdje na Gitlab te hebben gebruikt. Prima pakket en super lightweight. Build sinds kort nu ook mijn docker images daar ook naartoe.

[henk717]

Prima oplossing, in het laatste artikel uiten ik mijn ongenoegen omdat ik daar scripts heb staan met een lage populariteit die wel gebruikt worden maar niet bijgewerkt hoeven te worden en ook geen comments krijgen.

Ook al zou het nu 10 seconden duren voordat je mijn PulseAudio configuratie of Windows Local Account bypass script kunt downloaden is dat totaal niet erg want je kunt tenminste bij de files komen en het is niet populair of groot genoeg dat het aantal seconden veel uit maakt.

[qlum]

Dit lijkt me best een prima plan zo. Minder actieve projecten blijven wel gewoon behouden, dat deze nu op trage servers staan is niet erg.

Als ze echt verwijderd zouden worden is dat zonde, sims kan een project dat 5 jaar niet is aangeraakt toch in eens nuttig zijn.

[jaapzb]

Ja dat was ook niet zo slim