Re: Guix Docker image inflation

[Stephen Scheck]

On Fri, May 29, 2020 at 1:08 PM Leo Famulari <leo@famulari.name> wrote:

> I'm still not quite sure what you are doing (or what Docker does) so
> please bear with me.
>
> >     root@localhost /# du -h --max-depth=1 /gnu/store | egrep
> > "guix-system$|guix-packages-base$|guix-[0-9a-f]*-modules$"
> [...]
> >     191M
> /gnu/store/l3amdz5xyhflg5wdzlxr2685dq5glic2-guix-527ab3125-modules
> >     201M
> /gnu/store/5mhn1ynxvy7jihsknsnv3yspkkvc0r5s-guix-2e59ae238-modules
>
> If I understand correctly, you should not need both of these directories
> in a Guix VM image. The latter hashes are truncated guix.git commit
> hashes and a VM image would only be based on a single one.
>

Exactly, I agree (to the extent that I understand Guix).

I recommend looking into why all these directories are being copied into
> your images.
>

Whatever is in /gnu/store (as managed by Guix) goes into the image, nothing
more and nothing less.


>
> I figure you'd want to create each image with *only* the things
> corresponding to the Git commit it's based on, but it sounds like they
> are being created by copying the entire host image, which doesn't seem
> right.
>
> If the Docker images are being created by simply snapshotting the file
> system of a non-ephemeral Guix system, that's probably not the right way
> to do it. Is that what's going on?
>

Yes, as I said, the image is created from a file system snapshot, after Guix
is brought up to date via `guix pull` and those various Guix garbage
collection
operations are run. However, it's not quite "non-ephmeral" as each Guix
operation
is run as an atomic command inside the Docker container, with nothing else
running (except for guix-daemon, which has to always be running for Guix to
operate to the best of my understanding, and a couple other Guix System
daemons
which anyway would be equivalent to the situation to any Guix installation
running
outside of a Docker container).

How else would you suggest that it be done? It would be nice if `guix
system docker-image`
took `--branch` and `--commit` options to build a container from a
well-defined Guix check-in
state, but that doesn't seem to be the case. And in any case - too slow.
The point here is to
leverage daily incremental pulls to keep data transfer and build times down.