The existing infrastructure will always have more load and be more complex than what is needed for security updates. hydra is a fully general CI system, and properly so, but it means the system is subject to bugs and constraints that a simpler more focused system can avoid.
Moreover, for better or for worse hydra.nixos.org is only manageable by a small set of people who are not always available to service it (nor should they have to be!). No amount of improving hydra will fix that. ~Shea Graham Christensen <gra...@grahamc.com> writes: > -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://github.com/NixOS/nixos-org-configurations/tree/master/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 >> firstname.lastname@example.org >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>
Description: PGP signature
_______________________________________________ nix-dev mailing list email@example.com http://lists.science.uu.nl/mailman/listinfo/nix-dev