Re: [Nix-dev] Set up a Sufficiently Powerful Build Farm

[Chris Forno]

Peter Simons  cryp.to> writes:

> Anyhow, that's just a rough estimate. I don't know, really, what an ideal
> hardware / service platform for running such a virtual service would be. It
> would be great if a resident virtual server / NAS / system management guru
> could chime in with suggestions; I'm sure the NixOS crowd has people who know
> that kind of stuff and who can design the infrastructure for such a build
> farm.

I'd be happy to help, as I think I can use the experience to figure out
archiving build
sources ().
Ideally we can find a way to not only allow a user to populate a Nix store on
their machine with all sources for a given nixpkgs checkout but also to ship
the sources of all successful hydra builds to some long-term storage.

It would be interesting to also measure/project the storage required to
archive all builds produced by hydra across time.

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] hermetically sealed nixpkgs

[Chris Forno]

How would you go about (pre)fetching every source in the nixpkgs tree? How
large would you estimate the result to be (number of archives/space on
disk)?

In the last couple days:

* GNU bash silently updated patch 42 (
https://github.com/NixOS/nixpkgs/issues/11475)
* OpenSSL moved the 1.0.2d release to the "old" directory (breaking the
URL) (
https://github.com/NixOS/nixpkgs/commit/51a5f49d700890a93c36dd50e5eca4bf6ee6966b
)

These kind of breakages introduced by the external world erode the promise
of Nix that attracted me as a developer: reproducible builds into the
future. In this respect alone, Nix + a fixed nixpkgs checkout provides
little/no advantage over building in a VM: both work indefinitely as long
as you don't introduce new dependencies.

I intend to build/test a sort of hermetically sealed Nix where all
dependencies are frozen in time (saved somewhere). I suspect I'm not alone
in wanting this (
http://permalink.gmane.org/gmane.linux.distributions.nixos/18611). I'd
appreciate any tips/guidance/references to related work before I begin.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hiring more NixOS/NixOps developers (remote)

[Chris Forno]

We're hiring NixOS/NixOps developers for our DevOps team. We have ~100
servers running e-commerce systems that reach more than 1 million customers.

I posted here last December when we began switching our networks over from
Puppet to NixOps. The response was positive, and we now have a team of 3
very talented Nix developers working from around the world (the community
is small, and you've probably interacted with some of them).

We have a handful of machines now managed by NixOps, and we're getting
close to switching our entire network over. We're taking the time to do it
right and contributing improvements upstream when possible, and we need 1
or 2 more experienced Nix devs to help with the process (and continue on
with us after the switch).

Details are at
http://jobs.zalora.com/apply/lOd9Ir/Global-DevOps-Engineer-Remote.html?source=nd
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] hiring for NixOS/nixops DevOps (Singapore/remote)

[Chris Forno]

TL;DR: We're switching a 74-server network from Puppet to NixOS/nixops and
then expanding it. Apply at
http://jobs.zalora.com/apply/lOd9Ir/Global-DevOps-Engineer-Remote.html?source=nix-dev

After working with Puppet and discovering its shortcomings, we've decided
to switch our network over to NixOS/nixops. It's currently hosted as a mix
of Rackspace servers, Rackspace cloud, and AWS.

We've been hiring up Haskell developers (myself included) and applying
purely functional principles everywhere we can. Nix/NixOS was a breath of
fresh air when we discovered it. I have DevOps experience with an Alexa
top-150 site, but not much experience with Nix, and we need to hit the
ground running.

We have management's backing to do whatever is necessary to clean up the
existing system which is a bit of a mess (3 networks, each managed
separately with separate puppet instances, each slightly different from the
others). I envision the company becoming a major contributor to nixpkgs and
extending the system (we are dedicated to pushing changes back upstream).

I'm not familiar with the Nix community, but this might be the largest
customer-facing web application (in terms of number of users, if not
network size) that will be managed by Nix running NixOS. In order to
attract the best engineers, we're willing to hire remotely.

I'm happy to answer any questions you have.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev