Regarding different distros: yes, absolutely possible! Considering that swarm development is basically stopped the risk of inconsistencies is lower than back in the days but I’d pin the engine version on all nodes and only explicitly upgrade all at the same time to a newer version.

Regarding swarm itself, even though I understand your desire, I’d recommend to have a look at something else. Have you had a look at Nomad for instance? It’s not compose compatible but I guess these days it’s a simple prompt to convert the compose files, it’s supposed to be simpler than K8s and still offers many perks (like the failover you are looking for).

Also, from what I just read, Proxmox is working on improving the container support to allow “native” containers (inside VMs similar to Kata containers). They’re not there yet but I am wondering if it’s worth the effort from your side right now 😅

Either way, have fun! A fellow homelab buddy 😄

Haven’t copied it yet to an editor so just a few things:

• naming convention in Go is camelCase not snake_case
• prefer to accept io.Reader over opening files in every function. Improves testability but also is best practice
• return errors whenever possible instead of just logging them or do something about if you can (like creating a file if it doesn’t exist yet if it makes sense) - don’t use panic if you don’t have to! Panics are only a last resort if there’s no way to handle the error gracefully, think: compile a regex as a global variable that you need and that’s static, the expression won’t change magically so there’s no way the program can continue without a valid expression
• move logic to some package (== sub-directory with a package name != main) and have at least one function with a PascalCase name to call from you main package. Functions starting with a capital letter are public whereas functions starting with a lowercase letter are private - not by convention but enforced by the compiler!

For a more thorough review I’ve to get to a computer but probably someone else has some more tips for you :)

Also check out the docs for testing https://pkg.go.dev/testing should hopefully get you started

There’s also an experiment from the core dev team now: https://go.dev/blog/gonew that comes with 2 very basic templates that might be worth a look

I think this https://github.com/golang/go/discussions/56413 is the discussion.

Also an interesting read from Russ Cox: https://research.swtch.com/coro

I’d like to add that in my perception you’re a little bit overreacting. I can’t say that I got the same impression that you apparently got from the first comment. To me it sounds as if it’s primarily about missing some depth and could use some more advanced examples - especially when compared to the post Russ Cox wrote 😅 no offense!

I can imagine how…exhausting these discussions were 😅

Apart from the more synthetic examples and the obvious things like iterating custom containers - I understand your argument that this is not a every day use case but there are certainly some use cases - there are things like:

• iterating a bufio.Scanner
• iterating SQL results
• streaming chunked HTTP results

That can benefit from the range-over-func approach.

Furthermore there’s another “class” of tasks that are quite a good fit: generators 😍 Think of an infinite slice of random numbers or Fibonacci numbers or prime numbers…all of this can be expressed as a function you can iterate and “just stop” as soon as you have enough.

Probably this gives you an idea what else the whole experiment is good for 😉

Edit: there’s for instance a Python library letting you generate the holidays of a state for the next 1000 years based on some algorithm without having the data pre-calculated/stored anywhere but you can iterate/filter/… whatever you want

I tend to do manual bootstrapping with local execution as well but when using Forgejo/Gitea and corresponding actions you could also init the repo, start building your pipeline and use act to run it (locally at first if course) and as soon as you have your infrastructure in place you could continue to use the same pipeline there?

Still not ideal/perfect but if you don’t want to depend on some SaaS then this at least already runs the automation as it will be later?

Not crazy at all, actually, I can relate to some extent 😂 although, I am super happy with Talos on my nodes 😇 I feel like I am…staying familiar - love the optimism! - by building container images based on different distros simply because, depending on what you want to package, you’re…encouraged by the individual devs to use this or that package manager anyway 😂 but sounds like you do enjoy pain, so go for it 😂

If you don’t mind I’d be interested in how the cloudinit for proxmox looks like 😁 So far I only used it for Azure and Hetzner Cloud to bootstrap Coder machines but from your description I’d expect that should work. Very cool approach!