There's too much complexity inherent to the current FluxNode deployment paradigms (IMO). Sure, there are some nice scripts around, but they leave a considerable maintenance burden behind. Deployment via a Nix Flake providing a module could be an incredible boost for Flux deployments, handling the provisioning, configuration, and maintenance/upgrades of all required software packages and Flux-specific services with a modular declarative setup.
As a proof of concept, consider how easy it is to enable the "Ollama" AI service in a NixOS declarative configuration, including optional advanced configuration parameters:
services.ollama = {
enable = true;
acceleration = "rocm";
environmentVariables = {
HCC_AMDGPU_TARGET = "gfx1031";
};
rocmOverrideGfx = "10.3.1";
};
This small snippet is sufficient for downloading and installing the necessary software on the node, enabling the corresponding services, and configuration advanced configuration parameters. The same applies to a whole host of software and services available in the Nixpkgs archive.
In the case of a FluxNode, these configuration parameters would include Node/Account IDs, but could include other advanced overrides, like data directories, OCI runtime, etc.
Additionally, targeting NixOS Unstable (which is not as unstable as it sounds) would provide a rolling-release base for keeping nodes perpetually updated and secure.
I'd be willing to pitch in some help, but I don't have my bearings on the underlying components and how they fit together yet, and it would be really sweet if there was interest in adopting this approach upstream.
There's too much complexity inherent to the current FluxNode deployment paradigms (IMO). Sure, there are some nice scripts around, but they leave a considerable maintenance burden behind. Deployment via a Nix Flake providing a module could be an incredible boost for Flux deployments, handling the provisioning, configuration, and maintenance/upgrades of all required software packages and Flux-specific services with a modular declarative setup.
As a proof of concept, consider how easy it is to enable the "Ollama" AI service in a NixOS declarative configuration, including optional advanced configuration parameters:
This small snippet is sufficient for downloading and installing the necessary software on the node, enabling the corresponding services, and configuration advanced configuration parameters. The same applies to a whole host of software and services available in the Nixpkgs archive.
In the case of a FluxNode, these configuration parameters would include Node/Account IDs, but could include other advanced overrides, like data directories, OCI runtime, etc.
Additionally, targeting NixOS Unstable (which is not as unstable as it sounds) would provide a rolling-release base for keeping nodes perpetually updated and secure.
I'd be willing to pitch in some help, but I don't have my bearings on the underlying components and how they fit together yet, and it would be really sweet if there was interest in adopting this approach upstream.