I do own DS918+ with just received its last DSM update - 7.4 (you can skip the AI nonsense).

I am really happy with this purchase, as it’s been serving me well since 2018, and I hope it will run for few more years. I run ot it myriad of containers, and fairly recently I even tried moving some workloads from Hetzner to a local Ubuntu VM running on DSM. It’s packed with four 4TB WD Red HDDs since I owned, and in general whole unit has been hassle-free.

If you want to max out this unit further, you can consider the following.

Three years ago, I wrote about auto-ticketing flaky specs (dear lord, please slow down time maybe a bit? kthx).

In the time since, I was loosely consulting on a small/medium Rails project that was struggling with some technical debt - one aspect of which was a flaky test suite. The project had 231 flaky test reports, around 6,600 unit tests, and 342 feature specs running on RSpec, Capybara, and Selenium-Chrome.

Eventually, it reached 0 (zero) flaky tests - which, I think, makes it the only “production grade” project with such metrics I have ever seen in my life. So, one might ask - how can I get there?

Once again I did a full circle and got back to amd64 architecture, technically replacing everything I setup around 3 years ago. This time I will do it right.

After Hetzner rolled out their new cloud offering, it seems like AMD on Hetzner is kinda dead end at this point (don’t quote me on this). So I ended up in a weird situation where I had some old dangling ARM k3s node, some new PoC Coolify ARM-based server and it was time to put it all back together - obviously by setting up a third new project.

I wasted a few last weekends setting up a self-hosted runner set on a Kubernetes cluster just to… that’s actually a good question - I’ve already forgotten why.

So, I have a fairly easy CircleCI configuration for my Rails app. There are a few jobs running on different containers that prepare the dependencies cache, followed by some linters. Then, there are a few parallelized jobs that run tests, a fan-in job that collects test coverage results, and uploads them to Codecov. There’s also an optional step that builds a Docker image, pushes it to ECR, and optionally triggers ArgoCD deployments.

Almost a year ago, I wrote about how to deploy a simple MySQL leader/follower setup on Kubernetes.

It’s been a while, and I have decided to look into ‘operator’ solutions, which should be fully compatible with native MySQL implementations (MariaDB was out of the question because of reasons).

If you want something fully MySQL-compatible, you have two major options (I’m not going to mention operators, which seem to be abandonware at this point):

• Percona Server MySQL Operator - which went from technical preview to general availability fairly recently; it can run percona-server-mysql, which should be a drop-in MySQL 8.x replacement
• official MySQL-Operator from Oracle - where you just run official MySQL database (8.x/9.x)

I tested MySQL-Operator on a small testing cluster and decided to move my small workload after a month of battle testing. Migration was supposed to be a quick 20-minute adventure.

Another click-baity headline, don’t go, but hear me out, it’s a good idea.

Every now and then I try to look into “simpler” deployment options than my forgotten kubernetes cluster. I eventually abandoned nomad for k3s after running into constant pain from insufficient tooling. Then I forgot about that cluster for like 2 years and I’m waiting for an epic crash which would force me to redo the whole thing again.

Rollback to July 2003. I’m something like 17 years old, and I play video games. I mostly play Quake 3. And mostly Quake 3 with a DeFRaG mod.

We - and by we - I mean me with a group of random internet folks - just released something called “Polish Defrag MAPpack no.1” - 9 maps made by 9 different folks. I met those randos online on an internet forum located under q3arena.gry.wp.pl - a site which was moved around between domains since then, but that’s not the point.

You might be surprised by Rails’ behavior when rendering a partial via Turbo.

There is no session context - thus form_tag won’t render the “authenticity token” hidden field - it will silently omit it. This behavior was changed around 2021, and you can check out this lengthy discussion about the problem.

Nameserver limits were exceeded, some nameservers have been omitted.

Have you ever run into such errors on your k3s cluster?

The problem was already mentioned in a few places:

• https://vadosware.io/post/sometimes-the-problem-is-dns-on-hetzner/
• https://github.com/syself/cluster-api-provider-hetzner/issues/77

Some folks suggest modifying etc/resolved.conf, but as my node shipped with netplan (and I didn’t want to deal with that, I trust my hosting provider can handle networking), I decided to create a dedicated resolv config for kubelet needs.