<rekado_>provisioning the VM takes more than 3 seconds already
<PurpleSym>I think O2R/ERC are more concerned about post-research publication, which is why irreversibly freezing the results is probably fine for them.
<PurpleSym>(aka “see, you can run it and get the same results”-reproducibility)
<rekado_>then it has to boot, then it needs to do all the boring stuff that turn the generic AMI into something suitable for working with (e.g. “yum update -y” “yum install -y amazon-efs-utils”, mount any shared EFS for common data, mount block storage, etc)
<rekado_>you could make things a little faster by preparing an EBS volume with the relevant /gnu/store subset while the EC2 instance boots, and then attach it once the EC2 instance is ready.
<rekado_>but the mere act of copying data around is slow
<rekado_>(copying stuff also depends on features that Guix currently doesn’t expose: we need something between “guix copy” and “guix pack”, a file iterator of sorts, so that we can stream files to a target without intermediate packing)
<PurpleSym>I.e. `guix pack` streaming a tar archive to stdout.
<rekado_>for iterating on the same environment (e.g. running the thing again with an added package) you could get speed-up by listing just the files and piping the names to rsync to take care of the difference