Literally a complete rewrite, devouring whole thing with Nix and wg-bond #222
Conversation
Also deletion messages
wg-bond configuration management
|
Hmmm I'd like to ask the rest of the @subspacecommunity/subspace-maintainers about this, as far as I know, most people use this service with docker. I'd love to add support for Nix, but not at the expense of losing docker. |
|
We've PRd this half as joke, and half as a discoverability tool — and also we can build Docker images (requires some more work though) from that thing as well) |
|
heard some intresting things about nix, but its nature for system and deployment config is highly experimental AFAIK and the learning curve seems steep. What are the gains of potentally replacing the current set of automation toolings with nix? |
|
NixOS isn't experimental and works just fine in production, but alas you almost definitely do not want it to only work as a NixOS module unless you plan to only use NixOS (and you should of course but we haven't quite taken over the world yet). But as for the packaging with Nix, it is fully reproducible by design, both in the sense of keeping each build pure, but also being able to locally replicate everything, it also means if you don't want Docker, either out of convenience, necessity, or principle, you don't need it, because Nix doesn't suffer from the problems that make Docker useful to begin with for many use cases. This PR existing is as @cab404 said mostly a joke but if you're actually interested in upstreaming Nix/NixOS support it wouldn't be at the expense of Docker, we just removed it in our fork because we don't intend on ever using it, and it would have needed to be updated to support some changes we made. We probably would have made a more "compatible" PR for Nix support, if it weren't for us trying to get it to work for us in a hurry (and thus breaking Docker), and the fact that we also gutted and bastardized all of the actual Wireguard code in here in favor of internally using wg-bond to make it work properly for our use cases too, we doubt this would be upstreamed. If there's any actual interest in Nix support, we can at least upstream this part so so our diff doesn't have to be as big. We could also optionally alter the Docker stuff to just use Nix internally, which would provide some of the benefits of Nix, plus de-duplicate the packaging. I don't remember the exact issues we had with the existing Wireguard logic, but I remember it being slightly broken, didn't work with some subnets, and didn't work with how we run/orchestrate Wireguard (I think @cab404 remembers more details about this), so we just gutted the whole thing. I think it's unlikely you would be interested in this part, though it has some benefits, so I guess let us know if you are. |
Problem: Subspace fails to start on a fresh server due to lack of some configs and directories. Solution: Create these configs during service pre-start.
Problem: 'wg syncconf' doesn't work as expected and doesn't add routes for new peers. Solution: Restart interface via 'wg-quick' instead.
Fix subspace service pre-start script
|
Kudos, SonarCloud Quality Gate passed!
|
Problem: By default, systemd services generated from the NixOS system configuration don't attempt to restart on failure since Restart=no. However, in some cases, running processes can fail for unclear reasons, and the simplest way to bring the failed service back to life is to restart it. Instead, currently, the service will fail and trigger an alert without attempting to restart. Solution: Add default values for startLimitBurst, startLimitIntervalSec, Restart, and RestartSec.
[Chore] Add systemd unit restart policy
|
to:
cc: @subspacecommunity/subspace-maintainers
related to:
resolves:
Background
Reason for the change: It wasn't working as we wanted it to.
Changes
Testing
We tested it extensively.