[Nix-dev] Building appliances with nixos

[Bryce L Nordgren]

On Mon, Feb 27, 2012 at 10:12 PM, Marc Weber <marco-oweber at gmx.de> wrote:

> And then? Do the same as current buildfarm does? Duplicate work by
> building subversion revisions?
>

This dovetails pretty well with some thoughts which have recently been
hounding me. Currently, you have a generic nixpkgs tree for individual
libraries and applications. These are consolidated into "modules" for
things which tend to act as services.

I'm starting to fiddle with the notion of "appliances" within Nix. These
would consist of potentially customized nixpkgs, combined with a set of
commonly co-occuring services, and any "common" configuration which depends
on a known target environment (e.g., network filesystems, LDAP for users,
etc.). These would specifically exclude "instance" configuration elements,
like local filesystem mountpoints, boot configuration, etc. In essense,
appliances represent common configurations which could be independently
tested and shared, and which could exercise as much control as is needed
(e.g., an appliance/environment which requires a Ceph filesystem client
should track the latest kernel closely; whereas a self contained database
server may not have such a requirement).

In any case, one should not expect that, in general, a single master
definition of the nixpkgs tree will suit all needs. Appliance support will
bring /etc/nixos under version control (probably distributed version
control, like git), and each appliance will be defined by parallel branches
of /etc/nixos/nixos /etc/nixos/nixpkgs, and some appliance configuration in
/etc/nixos itself (as a peer to configuration.nix and
hardware-configuration.nix). I've been "tinkering" in github, at
https://github.com/bnordgren/nixappliance and its submodules.

I like the notion of appliances for a couple of reasons. They allow the
main nixpkgs tree to be updated willy nilly while simultaneously providing
a mechanism for identifying and promoting closures of well-tested software
systems. Why choose between stability and bleeding edge software when you
can have both? Upgrade to the testing appliance for a while, report issues,
then rollback when you get sick of dealing with headaches. Then once an
appliance has been rated "stable", it serves to offer a target for support.
(e.g., we can help you if you show us issues on the supported appliance,
but problems due to customizations are on your own head.--and in this case,
I'm not talking about the NixOS support list, I'm talking about an
organization which wants to offer linux devices.) Appliances are also an
attractive mechanism to define a target for "Certification and
Accreditation", which any security officer will require before the device
is permitted on an enterprise network.

Combine this with the fact that Nix is a provenance aware software
store...you add traceability and accountability for what software was added
by whom to which machines. More importantly, in the event of an "incident",
there is detailed information available to triage candidates for
"vulnerable" software packages and rapidly distribute replacements.

These "extra layers" of manageability, monitoring and accountability
inherent to Nix add up to an argument for me being able to download,
install, and use software without pre-approval. :) At least *I* think so.

In any case, appliances represent a use case for multiple hydra servers, as
each appliance might require different variants of the set of nixpkgs be
built (resulting in disjoint closures of software packages).

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120228/e1fce31f/attachment.html