Update on bordeaux.guix.gnu.org

Update on bordeaux.guix.gnu.org

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 3436 bytes --]

Hey!

It's been 3 months since I sent the last update [1]. This email was
meant to go out on Friday, but it seems opensmtpd was broken on my
machine, so it got stuck.

1: https://lists.gnu.org/archive/html/guix-devel/2021-08/msg00075.html

First, some good things:

I've been doing some performance tuning, submitting builds is now more
parallelised, a source of slowness when fetching builds has been
addressed, and one of the long queries involved in allocating builds has
been removed, which also improved handling of the WAL (Sqlite write
ahead log).

There's also a few new features. Agents can be deactivated which means
they won't get any builds allocated. The coordinator now checks the
hashes of outputs which are submitted, a safeguard which I added because
the coordinator now also supports resuming the uploads of outputs. This
is particularly important when trying to upload large (> 1GiB) outputs
over slow connections.

I also added a new x86_64 build machine. It's a 4 core Intel NUC that I
had sitting around, but I cleaned it up and got it building things. This
was particularly useful as I was able to use it to retry building
guile@3.0.7, which is extremely hard to build [2]. This was blocking
building the channel instance derivations for x86_64-linux.

2: https://data.guix.gnu.org/gnu/store/7k6s13bzbz5fd72ha1gx9rf6rrywhxzz-guile-3.0.7.drv

On the related subject of data.guix.gnu.org (which is the source of
derivations for bordeaux.guix.gnu.org, as well as a recipient of build
information), there have been a couple of changes. There was some web
crawler activity that was slowing data.guix.gnu.org down significantly,
NGinx now has some rate limiting configuration to prevent crawlers
abusing the service. The other change is that substitutes for the latest
processed revision of master will be queried on a regular basis, so this
page [3] should be roughly up to date, including for ci.guix.gnu.org.

3: https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-substitute-availability

Now for some not so good things:

Submitting builds wasn't working quite right for around a month, one of
the changes I made to speed things up led to some builds being
missed. This is now fixed, and all the missed builds have been
submitted, but this was more than 50,000 builds. This, along with all
the channel instance derivation builds that can now proceed mean that
there's a very large backlog of x86 and ARM builds which will probably
take at least another week to clear. While this backlog exists,
substitute availability for x86_64-linux will be lower than usual.

Space is running out on bayfront, the machine that runs the coordinator,
stores all the nars and build logs, and serves the substitutes. I knew
this was probably going to be an issue, bayfront didn't have much space
to begin with, but I had hoped I'd be further forward in developing some
way to allow moving the nars around between multiple machines, to remove
the need to store all of them on bayfront. I have got a plan, there's
some ideas I mentioned back in February [4], but I haven't got around to
implementing anything yet. The disk space usage trend is pretty much
linear, so if things continue without any change, I think it will be
necessary to pause the agents within a month, to avoid filling up
bayfront entirely.

4: https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00104.html

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Update on bordeaux.guix.gnu.org

[Ludovic Courtès]

Hello,

Christopher Baines <mail@cbaines.net> skribis:

> I've been doing some performance tuning, submitting builds is now more
> parallelised, a source of slowness when fetching builds has been
> addressed, and one of the long queries involved in allocating builds has
> been removed, which also improved handling of the WAL (Sqlite write
> ahead log).
>
> There's also a few new features. Agents can be deactivated which means
> they won't get any builds allocated. The coordinator now checks the
> hashes of outputs which are submitted, a safeguard which I added because
> the coordinator now also supports resuming the uploads of outputs. This
> is particularly important when trying to upload large (> 1GiB) outputs
> over slow connections.
>
> I also added a new x86_64 build machine. It's a 4 core Intel NUC that I
> had sitting around, but I cleaned it up and got it building things. This
> was particularly useful as I was able to use it to retry building
> guile@3.0.7, which is extremely hard to build [2]. This was blocking
> building the channel instance derivations for x86_64-linux.
>
> 2: https://data.guix.gnu.org/gnu/store/7k6s13bzbz5fd72ha1gx9rf6rrywhxzz-guile-3.0.7.drv

Neat!  (Though I wouldn’t say building Guile is “extremely hard”,
especially on x86_64.  :-))  The ability to keep retrying is much
welcome.

> On the related subject of data.guix.gnu.org (which is the source of
> derivations for bordeaux.guix.gnu.org, as well as a recipient of build
> information), there have been a couple of changes. There was some web
> crawler activity that was slowing data.guix.gnu.org down significantly,
> NGinx now has some rate limiting configuration to prevent crawlers
> abusing the service. The other change is that substitutes for the latest
> processed revision of master will be queried on a regular basis, so this
> page [3] should be roughly up to date, including for ci.guix.gnu.org.
>
> 3: https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-substitute-availability

That’s good news.  That also means that things like
<https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-reproducibility>
should be more up-to-date, which is really cool!  This can have a
drastic impact in how we monitor and address reproducibility issues.

> Now for some not so good things:
>
> Submitting builds wasn't working quite right for around a month, one of
> the changes I made to speed things up led to some builds being
> missed. This is now fixed, and all the missed builds have been
> submitted, but this was more than 50,000 builds. This, along with all
> the channel instance derivation builds that can now proceed mean that
> there's a very large backlog of x86 and ARM builds which will probably
> take at least another week to clear. While this backlog exists,
> substitute availability for x86_64-linux will be lower than usual.

At least it’s nice to have a clear picture of which builds are missing,
how much of a backlog we have, and what needs to be rebuilt.

> Space is running out on bayfront, the machine that runs the coordinator,
> stores all the nars and build logs, and serves the substitutes. I knew
> this was probably going to be an issue, bayfront didn't have much space
> to begin with, but I had hoped I'd be further forward in developing some
> way to allow moving the nars around between multiple machines, to remove
> the need to store all of them on bayfront. I have got a plan, there's
> some ideas I mentioned back in February [4], but I haven't got around to
> implementing anything yet. The disk space usage trend is pretty much
> linear, so if things continue without any change, I think it will be
> necessary to pause the agents within a month, to avoid filling up
> bayfront entirely.

Ah, bummer.  I hope we can find a solution one way or another.
Certainly we could replicate nars on another machine with more disk,
possibly buying the necessary hardware with the project funds.

Thanks for the update!

Ludo’.

Re: Update on bordeaux.guix.gnu.org

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

>> The disk space usage trend is pretty much
>> linear, so if things continue without any change, I think it 
>> will be
>> necessary to pause the agents within a month, to avoid filling 
>> up
>> bayfront entirely.
>
> Ah, bummer.  I hope we can find a solution one way or another.
> Certainly we could replicate nars on another machine with more 
> disk,
> possibly buying the necessary hardware with the project funds.

Remember that I’ve got three 256G SSDs here that I could send to 
wherever bayfront now sits.  With LLVM or a RAID configuration 
these could just be added to the storage pool — if bayfront has 
sufficient slots for three more disks.

-- 
Ricardo

Re: Update on bordeaux.guix.gnu.org

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> The disk space usage trend is pretty much
>>> linear, so if things continue without any change, I think it will
>>> be
>>> necessary to pause the agents within a month, to avoid filling up
>>> bayfront entirely.
>>
>> Ah, bummer.  I hope we can find a solution one way or another.
>> Certainly we could replicate nars on another machine with more disk,
>> possibly buying the necessary hardware with the project funds.
>
> Remember that I’ve got three 256G SSDs here that I could send to
> wherever bayfront now sits.  With LLVM or a RAID configuration 
> these could just be added to the storage pool — if bayfront has
> sufficient slots for three more disks.

Good to know.  In that case we’d need to come up with (1) an updated
Guix System config with LVM, and (2) a way to copy the existing store
over to the new storage, which sounds tricky if the existing disk is to
be kept.  (Also I think we’re down to 1.5 person who could go on
site. :-/)

Ludo’.

Re: Update on bordeaux.guix.gnu.org

[Ricardo Wurmus]

Hi,

[space is running out on bayfront, so I wrote:]

> Remember that I’ve got three 256G SSDs here that I could send to
> wherever bayfront now sits.  With LVM or a RAID configuration 
> these could just be added to the storage pool — if bayfront has
> sufficient slots for three more disks.

You wrote in response:

> Good to know.  In that case we’d need to come up with (1) an 
> updated
> Guix System config with LVM, and (2) a way to copy the existing 
> store
> over to the new storage, which sounds tricky if the existing 
> disk is to
> be kept.

We could first install Guix System with the adjusted bayfront 
config on a separate machine (e.g. on a build node at the MDC), 
onto a volume with LVM (using as many of the SSDs as needed). 
Copy signing keys etc from bayfront.  Then we’d pretty much 
export/import the bayfront store over the network.  Once 
everything has been copied, we turn off bayfront, swap the disks, 
boot it up again.  If everything works all right we add the 
original disk (and any unused left-over disks) to the LVM volume 
to extend the storage pool.

The trickiest bit is to minimize the time between finishing the 
sync and swapping the disks.

> (Also I think we’re down to 1.5 person who could go on
> site. :-/)

Not great :-/

-- 
Ricardo

Upgrading storage on bordeaux.guix.gnu.org

[Ludovic Courtès]

Hello!

(+Cc: Andreas.)

Ricardo Wurmus <rekado@elephly.net> skribis:

> [space is running out on bayfront, so I wrote:]
>
>> Remember that I’ve got three 256G SSDs here that I could send to
>> wherever bayfront now sits.  With LVM or a RAID configuration these
>> could just be added to the storage pool — if bayfront has
>> sufficient slots for three more disks.
>
> You wrote in response:
>
>> Good to know.  In that case we’d need to come up with (1) an updated
>> Guix System config with LVM, and (2) a way to copy the existing
>> store
>> over to the new storage, which sounds tricky if the existing disk is
>> to
>> be kept.
>
> We could first install Guix System with the adjusted bayfront config
> on a separate machine (e.g. on a build node at the MDC), onto a volume
> with LVM (using as many of the SSDs as needed). Copy signing keys etc
> from bayfront.  Then we’d pretty much export/import the bayfront store
> over the network.  Once everything has been copied, we turn off
> bayfront, swap the disks, boot it up again.  If everything works all
> right we add the original disk (and any unused left-over disks) to the
> LVM volume to extend the storage pool.

Sounds like a plan.  But note that there’s the store and there’s the
cached nars, though maybe we can tolerate missing, say, a week or two of
nars.

It would be more convenient to do that with a machine already in the
vicinity of bayfront though, so we can more easily move the disks there
when we’re ready.  Maybe we could use a machine at Inria or the math
institute next door.  Andreas, WDYT?  (We can work out the details
off-list.)

>> (Also I think we’re down to 1.5 person who could go on
>> site. :-/)
>
> Not great :-/

Here’s a call: if you’re in the whereabouts of Bordeaux, France, and
would like to help, please get in touch with Andreas and myself!  We
need to increase our tramway factor.

Cheers,
Ludo’.

Re: Upgrading storage on bordeaux.guix.gnu.org

[Maxim Cournoyer]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> (+Cc: Andreas.)
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> [space is running out on bayfront, so I wrote:]
>>
>>> Remember that I’ve got three 256G SSDs here that I could send to
>>> wherever bayfront now sits.  With LVM or a RAID configuration these
>>> could just be added to the storage pool — if bayfront has
>>> sufficient slots for three more disks.
>>
>> You wrote in response:
>>
>>> Good to know.  In that case we’d need to come up with (1) an updated
>>> Guix System config with LVM, and (2) a way to copy the existing
>>> store
>>> over to the new storage, which sounds tricky if the existing disk is
>>> to
>>> be kept.
>>
>> We could first install Guix System with the adjusted bayfront config
>> on a separate machine (e.g. on a build node at the MDC), onto a volume
>> with LVM (using as many of the SSDs as needed). Copy signing keys etc
>> from bayfront.  Then we’d pretty much export/import the bayfront store
>> over the network.  Once everything has been copied, we turn off
>> bayfront, swap the disks, boot it up again.  If everything works all
>> right we add the original disk (and any unused left-over disks) to the
>> LVM volume to extend the storage pool.
>
> Sounds like a plan.  But note that there’s the store and there’s the
> cached nars, though maybe we can tolerate missing, say, a week or two of
> nars.

I don't know anything about the Bayfront machine specifics, but if it
was running with a Btrfs file system, it could be extendable live by
adding the new drives to it in Btrfs RAID0 configuration.

Cheers,

Maxim

Re: Update on bordeaux.guix.gnu.org

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]


Ricardo Wurmus <rekado@elephly.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> The disk space usage trend is pretty much
>>> linear, so if things continue without any change, I think it will
>>> be
>>> necessary to pause the agents within a month, to avoid filling up
>>> bayfront entirely.
>>
>> Ah, bummer.  I hope we can find a solution one way or another.
>> Certainly we could replicate nars on another machine with more disk,
>> possibly buying the necessary hardware with the project funds.
>
> Remember that I’ve got three 256G SSDs here that I could send to
> wherever bayfront now sits.  With LLVM or a RAID configuration
> these could just be added to the storage pool — if bayfront has
> sufficient slots for three more disks.

While it would be nice for bayfront to have an SSD, it might actually be
more valuable to use those for some of the machines that do more of the
building.

harbourfront currently has a broken hard drive (I believe), and
milano-guix-1 has some slow hard drives that impede it building
things. I've CC'ed Andreas as I think he knows more about harbourfront,
and I'll follow up about milano-guix-1 off list.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Update on bordeaux.guix.gnu.org

[Ricardo Wurmus]

Christopher Baines <mail@cbaines.net> writes:

> [[PGP Signed Part:Undecided]]
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>>> The disk space usage trend is pretty much
>>>> linear, so if things continue without any change, I think it will
>>>> be
>>>> necessary to pause the agents within a month, to avoid filling up
>>>> bayfront entirely.
>>>
>>> Ah, bummer.  I hope we can find a solution one way or another.
>>> Certainly we could replicate nars on another machine with more disk,
>>> possibly buying the necessary hardware with the project funds.
>>
>> Remember that I’ve got three 256G SSDs here that I could send to
>> wherever bayfront now sits.  With LLVM or a RAID configuration
>> these could just be added to the storage pool — if bayfront has
>> sufficient slots for three more disks.
>
> While it would be nice for bayfront to have an SSD, it might actually be
> more valuable to use those for some of the machines that do more of the
> building.
>
> harbourfront currently has a broken hard drive (I believe), and
> milano-guix-1 has some slow hard drives that impede it building
> things. I've CC'ed Andreas as I think he knows more about harbourfront,
> and I'll follow up about milano-guix-1 off list.

Okay, thank you.

Note that these disks are (nominally) 250G each.  The spinning platter
disks might be larger than that, so this should be taken into account
when replacing disks.

-- 
Ricardo

Re: Update on bordeaux.guix.gnu.org

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 3242 bytes --]


Ludovic Courtès <ludo@gnu.org> writes:

> Christopher Baines <mail@cbaines.net> skribis:
>
>> I've been doing some performance tuning, submitting builds is now more
>> parallelised, a source of slowness when fetching builds has been
>> addressed, and one of the long queries involved in allocating builds has
>> been removed, which also improved handling of the WAL (Sqlite write
>> ahead log).
>>
>> There's also a few new features. Agents can be deactivated which means
>> they won't get any builds allocated. The coordinator now checks the
>> hashes of outputs which are submitted, a safeguard which I added because
>> the coordinator now also supports resuming the uploads of outputs. This
>> is particularly important when trying to upload large (> 1GiB) outputs
>> over slow connections.
>>
>> I also added a new x86_64 build machine. It's a 4 core Intel NUC that I
>> had sitting around, but I cleaned it up and got it building things. This
>> was particularly useful as I was able to use it to retry building
>> guile@3.0.7, which is extremely hard to build [2]. This was blocking
>> building the channel instance derivations for x86_64-linux.
>>
>> 2: https://data.guix.gnu.org/gnu/store/7k6s13bzbz5fd72ha1gx9rf6rrywhxzz-guile-3.0.7.drv
>
> Neat!  (Though I wouldn’t say building Guile is “extremely hard”,
> especially on x86_64.  :-))  The ability to keep retrying is much
> welcome.

To rephrase, I found it extremely hard to get that particular Guile
derivation to build successfully, it failed to build 12 times, and only
succeeded when I added new hardware to attempt on (I'm guessing the
particular issue I was encountering was exacerbated by more cores).

Unfortunately, I also think that you finding it easy to build actually
contributes to the problem here, since it makes finding and addressing
issues like this harder.

>> Space is running out on bayfront, the machine that runs the coordinator,
>> stores all the nars and build logs, and serves the substitutes. I knew
>> this was probably going to be an issue, bayfront didn't have much space
>> to begin with, but I had hoped I'd be further forward in developing some
>> way to allow moving the nars around between multiple machines, to remove
>> the need to store all of them on bayfront. I have got a plan, there's
>> some ideas I mentioned back in February [4], but I haven't got around to
>> implementing anything yet. The disk space usage trend is pretty much
>> linear, so if things continue without any change, I think it will be
>> necessary to pause the agents within a month, to avoid filling up
>> bayfront entirely.
>
> Ah, bummer.  I hope we can find a solution one way or another.
> Certainly we could replicate nars on another machine with more disk,
> possibly buying the necessary hardware with the project funds.

Since this email got a bit delayed when I sent it, things have moved on
a bit now.

90% disk usage was the threshold I had in mind for bayfront, and that's
now pretty much been reached so I've paused all the agents. My plans for
how to address this have also developed a bit as well, but it's still
going to take a month at least to get things going again.

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Update on bordeaux.guix.gnu.org

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]

Hey!

Around 2 months ago, bordeaux.guix.gnu.org came in to existence [1][2].

1: https://guix.gnu.org/en/blog/2021/substitutes-now-also-available-from-bordeauxguixgnuorg/
2: https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00044.html

This took work I'd done on providing substitutes back in 2020 and
attempted to bring benefits from that to normal users of Guix.

Unfortunately, I don't really know if this has been much of a
success. While it should be possible to track requests for substitutes
to roughly see if anyone is making use of them, this is something I
haven't been doing yet.

In terms of the substitute availability stats, I think it's delivered
the expected benefits. I recently enabled armhf-linux builds, so now
substitute availability for the following 5 architectures should be
good:

 - x86_64-linux
 - i686-linux
 - aarch64-linux
 - armhf-linux
 - powerpc64le-linux

You can use guix weather to check the stats yourself, or look at [3] for
an overview (ignore the ci.guix.gnu.org numbers, as they're not
currently up to date).

3: https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-substitute-availability

There's still some issues holding substitute availability back. The Guix
Build Coordinator still has issues building things that it can't garbage
collect. The majority of the issues though are actual problems, like
broken fixed output derivations, or generally broken packages.

The next steps in my mind remain roughly the same as they were 2 months
ago:

 - It would be good to have something to provide more visibility in to
   the Guix Build Coordinator as well as the submitting of the builds

 - Supporting performant mirroring would be great, and I have some ideas
   of how to go about this

 - I did previously have some success building things for the Hurd [4],
   and it would be great to try and replicate this on
   bordeaux.guix.gnu.org

 - data.guix.gnu.org performance in processing new revisions is a
   limiting factor, so improving this would be helpful

 - Having aggregate statistics on use of substitutes (splitting out
   machines in the build farm) would be good for assessing use and
   changes in use

 - More hardware would be good for build throughput and redundancy. For
   example, there's currently only two ARM build machines linked up, and
   I host both of them.

4: https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00074.html

If you're interested in getting involved, or have any comments or
questions, please just let me know!

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Update on bordeaux.guix.gnu.org

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On 2021-08-18, Christopher Baines wrote:
> Around 2 months ago, bordeaux.guix.gnu.org came in to existence [1][2].
>
> 1: https://guix.gnu.org/en/blog/2021/substitutes-now-also-available-from-bordeauxguixgnuorg/
> 2: https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00044.html
>
> This took work I'd done on providing substitutes back in 2020 and
> attempted to bring benefits from that to normal users of Guix.
>
> Unfortunately, I don't really know if this has been much of a
> success.

I can definitely speak from experience the likelihood of actually
getting substitutes for any aarch64 linux-libre* packages has gone from
"rarely" to "usually", so it has definitely been a huge improvement for
aarch64, where building locally on most aarch64 hardware is very slow.

Does it have faster build machines? Does it keep retrying until it
succeeds? Building linux-libre* packages for ci.guix.gnu.org usually
timeout when building the source due to long periods with no output...


live well,
  vagrant


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Update on bordeaux.guix.gnu.org

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]


Vagrant Cascadian <vagrant@debian.org> writes:

> On 2021-08-18, Christopher Baines wrote:
>> Around 2 months ago, bordeaux.guix.gnu.org came in to existence [1][2].
>>
>> 1: https://guix.gnu.org/en/blog/2021/substitutes-now-also-available-from-bordeauxguixgnuorg/
>> 2: https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00044.html
>>
>> This took work I'd done on providing substitutes back in 2020 and
>> attempted to bring benefits from that to normal users of Guix.
>>
>> Unfortunately, I don't really know if this has been much of a
>> success.
>
> I can definitely speak from experience the likelihood of actually
> getting substitutes for any aarch64 linux-libre* packages has gone from
> "rarely" to "usually", so it has definitely been a huge improvement for
> aarch64, where building locally on most aarch64 hardware is very slow.

That's good to hear. Unfortunately I only got around to enabling
armhf-linux builds last week, but now there should be good substitute
availability for armhf-linux as well.

> Does it have faster build machines? Does it keep retrying until it
> succeeds? Building linux-libre* packages for ci.guix.gnu.org usually
> timeout when building the source due to long periods with no output...

Currently for arm builds, there's a Overdrive machine (monokuma) and a
Honeycomb machine. I would guess that the Honeycomb machine is faster,
but I haven't really compared the performance.

I do have the guix-daemon timeouts set to pretty high values (max silent
time of 12 hours, timeout of 24 hours) which is probably necessary for
the linux-libre* packages.

There's also automatic retries, a failed build will be retried
twice. That's more relevant for things that sometimes fail to build
though, or fail to build on particular hardware, rather than timeouts.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]