From: Enrico Schwass <ennoausberlin@me.com>
To: Efraim Flashner <efraim@flashner.co.il>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
guix-devel@gnu.org, guix-sysadmin <guix-sysadmin@gnu.org>
Subject: Re: Sustainable funding and maintenance for our infrastructure
Date: Mon, 8 Jul 2024 19:21:38 +0200 [thread overview]
Message-ID: <80763E6E-2F9E-415C-9A9C-E6B980233BD3@me.com> (raw)
In-Reply-To: <ZowTcLttHxL1rdJ6@pbp>
Hi Guix
If you are looking for host services
I have good experience with netcup.de. They also have ARM machines.
My 3 machines have a great uptime
Bye
Enno
> Am 2024/07/08 um 18:28 schrieb Efraim Flashner <efraim@flashner.co.il>:
>
> On Tue, Jul 02, 2024 at 04:24:06PM +0200, Ludovic Courtès wrote:
>> Hello Guix!
>>
>> We (Andreas, Chris, Ricardo, Romain, and myself) were having a
>> discussion about what it would take to set up a build farm similar to
>> what’s behind ci.guix: roughly 30 x86_64 servers, with 32-core/64-thread
>> CPUs and 128 GiB of RAM. The reason for this discussion is that we were
>> thinking that we should not take our existing build farms for granted
>> and be prepared for the future.
>>
>> The various options and back-of-the-envelope estimates we came up with
>> are as follows:
>>
>> 1. Buying and hosting hardware:
>> 250k€ for hardware
>> 3k€/month (36k€/year)
>>
>> 2. Renting machines (e.g., on Hetzner):
>> 6k€/month (72k€/year)
>>
>> 3. Sponsored:
>> get hardware and/or hosting sponsored (by academic institutions or
>> companies).
>>
>> Option #1 gives us “full control”, the downside being that it’s a lot of
>> work and a real burden (get crowdfunding for the initial funding, later
>> on to sustain funding to cover hosting, ensure Guix Foundation is up to
>> the task of managing the assets, and of course to take care of the
>> machines for their entire lifecycle).
>>
>> Option #2 gives us less control (we don’t know exactly what hardware is
>> being used and have to trust the company hosting the machines). The
>> upside is that it’s much less work over time (the company is responsible
>> for upgrading hardware) and less work initially (no need to raise as
>> much money to buy hardware).
>>
>> Option #3 potentially gives less control (depending on the project’s
>> relation with the hosting organization) and makes the project dependent
>> on the sponsor and/or person(s) in touch with them. On the upside, it
>> could significantly reduce costs (potentially to 0€).
>>
>>
>> This is an important topic for the project, one we should plan for:
>> socially, financially, technically. This takes time, which is why
>> preparation is needed.
>>
>> What do people think?
>>
>> Ludo’ & co.
>
> Looking at Hetzner, they have an option to rent a dedicated ARM server
> with 80 cores/threads with 256GB of RAM and 2x3.84 TB NVMe drives for
> under €300/month and a €94 setup charge. Correct me if I"m wrong, but
> that one box is ~20x our current active aarch64/armv7 capacity.
>
> Also looking at our current infrastructure at MDC, part of the reason we
> have so many x86_64 machines is because that's what was bought with the
> donated money, not because we actually needed quite that many, so some
> of the numbers might be higher than we actually need.
>
> --
> Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
> <signature.asc>
> Am 2024/07/08 um 18:28 schrieb Efraim Flashner <efraim@flashner.co.il>:
>
> On Tue, Jul 02, 2024 at 04:24:06PM +0200, Ludovic Courtès wrote:
>> Hello Guix!
>>
>> We (Andreas, Chris, Ricardo, Romain, and myself) were having a
>> discussion about what it would take to set up a build farm similar to
>> what’s behind ci.guix: roughly 30 x86_64 servers, with 32-core/64-thread
>> CPUs and 128 GiB of RAM. The reason for this discussion is that we were
>> thinking that we should not take our existing build farms for granted
>> and be prepared for the future.
>>
>> The various options and back-of-the-envelope estimates we came up with
>> are as follows:
>>
>> 1. Buying and hosting hardware:
>> 250k€ for hardware
>> 3k€/month (36k€/year)
>>
>> 2. Renting machines (e.g., on Hetzner):
>> 6k€/month (72k€/year)
>>
>> 3. Sponsored:
>> get hardware and/or hosting sponsored (by academic institutions or
>> companies).
>>
>> Option #1 gives us “full control”, the downside being that it’s a lot of
>> work and a real burden (get crowdfunding for the initial funding, later
>> on to sustain funding to cover hosting, ensure Guix Foundation is up to
>> the task of managing the assets, and of course to take care of the
>> machines for their entire lifecycle).
>>
>> Option #2 gives us less control (we don’t know exactly what hardware is
>> being used and have to trust the company hosting the machines). The
>> upside is that it’s much less work over time (the company is responsible
>> for upgrading hardware) and less work initially (no need to raise as
>> much money to buy hardware).
>>
>> Option #3 potentially gives less control (depending on the project’s
>> relation with the hosting organization) and makes the project dependent
>> on the sponsor and/or person(s) in touch with them. On the upside, it
>> could significantly reduce costs (potentially to 0€).
>>
>>
>> This is an important topic for the project, one we should plan for:
>> socially, financially, technically. This takes time, which is why
>> preparation is needed.
>>
>> What do people think?
>>
>> Ludo’ & co.
>
> Looking at Hetzner, they have an option to rent a dedicated ARM server
> with 80 cores/threads with 256GB of RAM and 2x3.84 TB NVMe drives for
> under €300/month and a €94 setup charge. Correct me if I"m wrong, but
> that one box is ~20x our current active aarch64/armv7 capacity.
>
> Also looking at our current infrastructure at MDC, part of the reason we
> have so many x86_64 machines is because that's what was bought with the
> donated money, not because we actually needed quite that many, so some
> of the numbers might be higher than we actually need.
>
> --
> Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
> <signature.asc>
next prev parent reply other threads:[~2024-07-08 17:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-02 14:24 Sustainable funding and maintenance for our infrastructure Ludovic Courtès
2024-07-03 1:13 ` indieterminacy
2024-07-04 16:37 ` Simon Tournier
2024-07-08 12:02 ` Ricardo Wurmus
2024-07-09 14:49 ` Simon Tournier
2024-07-11 9:23 ` Ludovic Courtès
2024-07-08 15:46 ` Vagrant Cascadian
2024-07-08 18:28 ` Vincent Legoll
2024-07-09 9:47 ` Tomas Volf
2024-07-11 10:33 ` Andreas Enge
2024-07-11 20:44 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-07-11 9:38 ` Ludovic Courtès
2024-07-12 10:44 ` Simon Tournier
2024-07-21 12:52 ` Ludovic Courtès
2024-07-08 16:27 ` Efraim Flashner
2024-07-08 17:21 ` Enrico Schwass [this message]
2024-07-11 10:48 ` Andreas Enge
2024-07-11 9:28 ` Ludovic Courtès
2024-08-01 22:11 ` Marek Paśnikowski
2024-08-13 2:53 ` Jonathan Frederickson
2024-08-13 16:23 ` Sergio Pastor Pérez
2024-08-13 23:38 ` Jonathan Frederickson
2024-08-14 13:21 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-08-24 23:15 ` Jonathan Frederickson
2024-08-21 22:07 ` P2P Guix package building and distribution Christine Lemmer-Webber
2024-08-22 9:05 ` Andreas Enge
2024-08-22 21:57 ` Samuel Christie via Development of GNU Guix and the GNU System distribution.
-- strict thread matches above, loose matches on Subject: below --
2024-07-02 14:26 Sustainable funding and maintenance for our infrastructure Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80763E6E-2F9E-415C-9A9C-E6B980233BD3@me.com \
--to=ennoausberlin@me.com \
--cc=efraim@flashner.co.il \
--cc=guix-devel@gnu.org \
--cc=guix-sysadmin@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.