-1 I think a better approach would be to bolster and support the existing
infrastructure and fix its issues, not create a whole new set. Hydra
already spins up and down AWS nodes depending on the number of jobs.

 - https://github.com/NixOS/hydra-provisioner
 - https://hydra.nixos.org/machines -- I believe if you whois the
struck-out IPs they'll all belong to AWS

On Sun, Oct 16, 2016 at 12:56 PM Shea Levy <s...@shealevy.com> wrote:

> Hi all,
> hydra.nixos.org is a wonderful community resource, but its broad scope
> and somewhat frequent downtime concerns me when it comes to security
> updates. As a supplemental service, I propose we have a service, hosted
> by a professional hosting company with 24/7 support and with multiple
> trusted community members having administrative access, dedicated to
> building only critical security updates and uploading them to the binary
> cache, with the intention that these be used with
> system.replaceRuntimeDependencies/pkgs.replaceDependency until hydra has
> had a chance to update the entire channel. This service could work via
> manual triggering by trusted users, github push notifications and commit
> message parsing (to get the relevant attributes to build), signed git
> commits, or some combination of these, and would *only* build the
> directly affected packages (e.g. only rebuild glibc for a glibc
> vulnerability, expecting users to use replaceDependency until hydra is
> caught up). If it turns out to be useful, it could spin up AWS build
> machines on demand to ensure a very rapid turnaround.
> Thoughts on this? I'm happy to help fund this significantly, but it
> loses a lot of its value if it doesn't directly upload to the nixos.org
> cache so I think it needs official support before following through.
> Thanks,
> Shea
> _______________________________________________
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
nix-dev mailing list

Reply via email to