Boris Marinov

So I finally finished (most) work on my Garage storage controller. And motivated myself to even write a short post about it.
https://borismarinov.de/writing/s3-garage-storage-controller

Comments @ mastodon only, feedback welcome.
Source: https://github.com/bmarinov/garage-storage-controller
#garage #s3 #kubernetes #selfhosted #homelab

There was a bit of noise around Garage (S3) recently, so hopefully this is relevant to someone here.

I've been working on a #kubernetes controller project for the declarative management of S3 buckets and access keys.

https://github.com/bmarinov/garage-storage-controller

It was originally intended for developer self-service scenarios in medium+ sized orgs. But not having to script this or do it manually in the #homelab has been really nice too.

I am running it in a few environments and could really use more eyes on it, and fresh ideas about what's missing.

Disclaimer:
I've been working on this on and off since early December and I finally feel comfortable to post about it here. As its touching something as crucial as storage I feel inclined to mention that the whole project is exactly 0% vibe coded slop.

My plan for the next few weeks is to add few missing things: e.g. a Helm chart, better metrics, and Ops QoL improvements. o7

#selfhost #garage @homelab@fedigroups.social

@jankatins@fosstodon.org Hey, thanks for the question! The comparison was very focused on our specific scenario - two DCs, rather mediocre network storage and high availability on the read path (can tolerate one DC going down, but no quorum for writes).

By the time I strip all the company specifics, there will be barely anything left worth reading.

A very short summary of some alternatives I looked into:

• ceph - a beast to operate just for S3. 
• rook - easier but our network storage is (still) inadequate.
• Seaweedfs: didn't test, looked solid (features!), some aspects gated behind enterprise; and procurement is tons of pain here.
• RustFS - I better not comment on that one publicly.

Other than clustering, other factors included:

• issue count / commit activity
• focused solution vs offering everything
• projects with far too much "development activity" and features in relation to the age

There are a ton of new and hot alternatives and I am not betting on the ability of random people to use LLMs in moderation. So several candidates were not considered at all.

Yesterday I worked on a #terraform postgres module wrapping another #incus module for good two hours. Some hard lessons were learned.
So at this point I am three modules deep, reorganizing them as I go while trying to keep things simple and repeatable. Wait for that cloud-init, set up them users and hba conf, lock down config, yadda yadda.

I thought that I can wait for postgres to report ready, the port to be up before I hand over to the pg provider which handles the database creation. Connection refused :D time and time again.
With feedback loops of a few minutes I wasted quite a bit of time before I figured out I should be building base images with (here) #postgres and not installing it and extensions fresh every time I spin up something.

So today it is time to look into distrobuilder finally. And where I can host my own incus/lxc images.