If I where to seek to get a a nix build handle onto k3os, how would I start?
- Ditches systemd for openRC
- Seems to rebuild — based on docker workflows and bash scripts — quite some of the nix native build machinery
1 Like
I was under the impression that one of the benefits of k3OS was it can be configured from the k3s/kubernetes that it’s running. Like coreos & flatcar I don’t think you’re meant to install anything natively, everything is meant to be ran through containers.
All configuration is done through a single cloud-init style config file that is either packaged in the image, downloaded though cloud-init or managed by Kubernetes.
I guess you could use nix to build out cloud-init style config files that can be downloaded through cloud-init.
Or you might be able to use nix to remaster the ISO for initial install but that’s not really what you’re aiming for 
I once investigated on this a while ago: to my taste the auto-upgrades done arbitrarily by a in-cluster controller are a bit too much. Since we’re managing the rest of the infrastructure with morph, it would be handy to remaster the iso in a way that could be deployed nix-natively with morph along with the rest of the non-k8s infrastructure.
Thanks for your ideas! I’m trying to collect some opinions and feedback so that once I might eventually kick this off, there is a fundus to draw upon.
EDIT: I think nix based remastering also comes in handy when special kernel modules are required (in our case rtpengine with in-kernel packet forwarding).
EDIT2: Thank you for the remastering glossary. I think that’s what I’m actually aiming for. 
Glad to have helped 