<div dir="ltr">Hi Ben,<div><br></div><div>Tweag is going to pick-up the tab for this. I will send you AWS credentials in a few.</div><div><br></div><div>If all you want is a S3-compatible API, I have also deployed minio successfully in the past. There are a few gotchas but it could be a nice alternative.</div><div><br></div><div>Best,</div><div>Jonas</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 23, 2019 at 12:38 AM Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> writes:<br>
<br>
> I think it would probably help to summarise all the costs that we are<br>
> currently incurring, and who is currently paying for them (including<br>
> in-kind contributions). That would help to give perspective.<br>
><br>
Yes, that is a great idea.<br>
<br>
>From the top of my head here is a quick summary; currently all of our<br>
costs except for S3 are covered by in-kind donations (thank you<br>
everyone!):<br>
<br>
 * Who: Google X<br>
   What: Google Compute Engine credit<br>
     * currently 4x 8-core x86-64/Windows instances<br>
   Why: Currently used exclusively for Windows CI builds<br>
        although we aren't using the entire credit<br>
   Cost: In-kind donation<br>
<br>
 * Who: Packet.net<br>
   What: Computers<br>
     * 2x 8-core x86-64/Linux machines<br>
     * 1x 48-core AArch64/Linux machine<br>
   Why:<br>
     * GitLab hosting<br>
     * CI builders<br>
     * various non-GHC services (Hackage, Hackage documentation<br>
       builder, <a href="http://haskell.org" rel="noreferrer" target="_blank">haskell.org</a> web hosting)<br>
   Cost: In-kind donation<br>
<br>
 * Who: Futurice<br>
   What: Computers<br>
     * 1x Mac Mini<br>
   Why:<br>
     * Mac OS X builder<br>
   Cost: In-kind donation<br>
<br>
 * Who: Davean Scies<br>
   What: Computers<br>
     * 2x x86-64/Darwin Mac Minis<br>
   Why:<br>
     * Mac OS X builders<br>
   Cost: In-kind donation<br>
<br>
 * Who: Ben Gamari<br>
   What: Computers<br>
     * 1x 16-core x86-64/Linux machine<br>
     * 1x 64-core x86-64/Linux machine<br>
   Why:<br>
     * CI builders<br>
   Cost: In-kind donation<br>
<br>
 * Who: Alp Mestanogullari<br>
   What: Computers<br>
     * 1x 12-core x86-64/Linux machine<br>
   Why:<br>
     * CI builder<br>
   Cost: In-kind donation<br>
<br>
 * Who: GitLab<br>
   What: A GitLab Ultimate license<br>
   Why:<br>
     * Hopefully this is self-explanatory<br>
   Cost: In-kind donation<br>
<br>
I do hope I haven't forgotten anyone.<br>
<br>
> Not incurring costs unnecessarily is obviously the first step, so your<br>
> second message (with good news about reducing storage costs) is great.<br>
> If the remaining monthly cost still looks high, we should review<br>
> whether we want to keep everything we are keeping. Does anyone ever<br>
> look at this stuff?<br>
><br>
Preserving binary distributions serves two purposes:<br>
<br>
 * preserving `master` commits allows for easy bisection; I think this<br>
   is quite important since bisection is frequently the fastest way to<br>
   home in on a regression .<br>
<br>
 * preserving MR artifacts allows users to easily use and share the<br>
   results of their builders; given that we have burned the carbon to<br>
   produce the build, it seems wasteful to immediately throw away the<br>
   result given how cheap storage is. Facilitating this is the purpose<br>
   of the ghc-artefact-nix tool which mpickering recently wrote about on<br>
   ghc-devs.<br>
<br>
Now since we have avoided the worst of transfer costs it seems to me<br>
that the cost preserving these artifacts is well-justified.<br>
<br>
> You should not have to pay for anything personally!<br>
><br>
Of course, to be clear I don't intend on continuing to pay the AWS<br>
costs; the bucket merely ended up on my account since this was the<br>
easiest way to get started. The plan was to then bring the issue with<br>
ghc-devops after we had a better idea of what the costs look like.<br>
Admittedly, I expected the bill to be a bit lower than it ended up<br>
being.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
_______________________________________________<br>
Ghc-devops-group mailing list<br>
<a href="mailto:Ghc-devops-group@haskell.org" target="_blank">Ghc-devops-group@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group</a><br>
</blockquote></div>