Skip to content

Tarook @ ALASCA Hackathon – Task Descriptions

Three independent tasks, to be worked on in parallel by different people/teams.

New to Nix? Getting started

Repository for the workshop: https://gitlab.com/alasca.cloud/tarook/alasca-hackathon-2026

All three tasks involve the Nix language/package manager.

To install Nix locally, see our quick-start guide

Just want to try it without installing anything? Boot the NixOS live ISO in a VM, or use the official Docker image: docker run -it nixos/nix.

For a hands-on introduction to the language and core concepts, the official Nix tutorial is a good starting point. Full installation details and platform-specific notes: nixos.org/download.

Useful resources for working with Nix:

  • search.nixos.org – official search for packages, NixOS options, and flakes
  • MyNixOS – community search across packages, NixOS/Home Manager/nix-darwin options, and flakes
  • Noogle – search engine for Nix/nixpkgs functions, useful when you need a specific lib/builtins function
  • Awesome Nix – curated list of Nix tools and projects
  • NixOS Wiki – community wiki with practical how-tos and troubleshooting

How to work on these tasks

  1. Fork this repository.
  2. Pick one of the three tasks below to work on.
  3. Work on your fork/branch for the duration of the hackathon.
  4. Submit your result as a merge request against the original repository.

Task 1: Kubernetes packages for Nix

Background

Nix draws its packages primarily from nixpkgs, the central package repository of the Nix ecosystem. Kubernetes is maintained there as a single package – meaning there is only one version available, and upgrading it is tied to nixpkgs' own release cycle. This is a problem for Tarook: cluster operators need to be able to flexibly choose and switch between Kubernetes versions supported upstream (see kubernetes.io/releases), independent of whatever version nixpkgs happens to currently package.

The current nixpkgs Kubernetes package can serve as a reference: package.nix.

Goal

At minimum, all Kubernetes minor versions currently supported upstream should be independently installable via Nix.

Possible approaches (for inspiration, not exhaustive):

  • One Nix package per minor version (e.g. kubernetes136, kubernetes135, …), similar to the versioning pattern used for Python in nixpkgs (python311, python312, …)
  • A Git repository with tags per patch version as the basis for the package definitions
  • Mid-term: upstreaming the solution into nixpkgs itself

Definition of Done

💡 An OpenStack project will be provided so you can try out and test your image directly during the hackathon.

  • Research findings documented: what existing solutions/approaches are already out there (in nixpkgs, in other repos, in the community)? Are there already discussions about the Kubernetes package?
  • At least one working proof of concept that provides two different Kubernetes minor versions in parallel via Nix
  • An idea for how to handle individual patch versions within each package

Task 2: NixOS cloud image for OpenStack

Background

For Tarook to manage NixOS VMs in the future, it needs NixOS cloud images that behave in OpenStack just as the Ubuntu/Debian cloud images used today: automatically resizing the root disk on boot, automatically deploying SSH keys via cloud-init or similar.

Helpful starting points for research:

Goal

Goal 1: A generic NixOS image that can be published as a public image in OpenStack and behaves like a standard cloud image (root disk resize, SSH key deployment, etc.).

Goal 2: Building on that, parametrizable NixOS images that can be customized per OpenStack project (e.g. different configurations per Tarook deployment).

Definition of Done

Goal 1:

  • Research findings documented: what existing NixOS-OpenStack image solutions exist, and how well do they cover Goal 1?
  • A working NixOS image that can be launched as an instance in OpenStack and correctly performs root disk resize and SSH key deployment on boot
  • Brief documentation of how the image is built (build instructions/reproducibility)

Goal 2:

  • At least one concrete proposal/proof of concept for what per-OpenStack-project parametrization could look like

Task 3: Migrating configuration templates to NixOS

Background

On gateway and Kubernetes nodes, Tarook configures several central infrastructure services via Ansible templates – including keepalived (VRRP/failover), haproxy (load balancing), nftables (firewalling), and bird (routing/BGP). These configurations are currently designed as classic configuration files deployed via Ansible onto Ubuntu/Debian systems.

For these services to run on NixOS nodes, the corresponding configurations need to be migrated into declarative NixOS modules/options – in line with Nix's declarative paradigm, rather than as plain template files.

Goal

The existing configuration templates for keepalived, haproxy, nftables, and bird should be migrated into equivalent, working NixOS configurations (via the respective NixOS modules/options), so that the same functionality is achieved on a NixOS system as is currently achieved on Ubuntu/Debian.

Definition of Done

  • Research findings documented: what NixOS modules already exist for keepalived, haproxy, nftables, and bird, and how well do they cover the required functionality?
  • For at least two of the four services: a working NixOS configuration that demonstrably shows the same behavior in a test environment (e.g. VM or container) as the existing Ansible template solution
  • A short list of open issues/gaps per service, in case NixOS modules don't fully cover the requirements