#trying out _EXPERIMENTAL_DAGGER_CACHE_CONFIG but seems to be not working

1 messages Β· Page 1 of 1 (latest)

lean jackal
#

Hi, i'm currently trying the _EXPERIMENTAL_DAGGER_CACHE_CONFIG using s3 and registry. From the logs, it seems to be working

11: importing cache manifest from s3:17471463523230677791
11: importing cache manifest from s3:17471463523230677791 
...
...
...
25: exporting cache to Amazon S3
25: preparing build cache for export 
25: writing layer sha256:ab9a9dd810c0dc1bf1f6b911095d8f85f3b7e8d22e633e060e6f980b59ad3d23 
25: writing layer sha256:ab9a9dd810c0dc1bf1f6b911095d8f85f3b7e8d22e633e060e6f980b59ad3d23 [0.01s]
25: writing layer sha256:c2ddf4c33d7561bc63d9b4cd20b5645a4528c37599dacbf0ed6b8e4df1fda6bf 
25: writing layer sha256:c2ddf4c33d7561bc63d9b4cd20b5645a4528c37599dacbf0ed6b8e4df1fda6bf [0.01s]
25: writing layer sha256:c798134b5a2faa32b79b83ed0bf6b50a0117ee247c05afcb9f44ff6fd977b17c 
25: writing layer sha256:c798134b5a2faa32b79b83ed0bf6b50a0117ee247c05afcb9f44ff6fd977b17c [0.02s]
25: preparing build cache for export [0.27s]
25: exporting cache to Amazon S3 DONE

but if i re-run the pipeline after deleting the volume of dagger engine, it runs like it has no cache at all. Did i miss something? i see something similar in https://github.com/moby/buildkit/issues/2274, does it relates?

GitHub

concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit - Issues Β· moby/buildkit

dark walrus
#

Hi @lean jackal πŸ‘‹ I know there are gotchas for using the basic buildkit cache. Because we want something solid that also has better performance through enhancements like caching of volumes (like for pip cache), etc, we've been investing in the Dagger cache service. Happy to show that to you if you're interested πŸ™‚

Unfortunately I don't know the solution to the issue you're hitting.

proper jewel
#

seems to be related to buildkit. Unfortunately, we're not using buildkit's default exporter since it's known to have a some gotchas as well as unresolved issues upstream. That's why we're investing to build our own distributed cache solution which resolves this issues plus adding some more efficient caching.

lean jackal
#

Thanks for the response. I ended up using tar+rclone to backup and restore /var/lib/dagger.

lean jackal
#

Hi @proper jewel , any gotchas that you can think of when using tar to store the /var/lib/dagger ?.
i'm seing "some" cache miss when using restored cache that was stored using tar+rclone.

proper jewel
lean jackal
#

yups 0.6.4

proper jewel
#

In that case there shouldn't be a difference. Would be nice to have a minimal repro case so we can look further, but rcloning the data directory should work

lean jackal
#

right, let me try to create repro

proper jewel
lean jackal
#

i'm rclone-ing a tar-ed dirrectory

proper jewel
lean jackal
#

wait, the cache miss is even before using restored cache.

in my CI, i tried running the same dagger pipeline twice (without even stopping the engine), but cache missed happens. on the second run, it pulls the same image pulled on the first run πŸ€”

lean jackal
#

re-running the same pipeline using docker-compose using another maching does not lead to cache miss.

the CI is jenkins and the agent is running under kubernetes, /var/lib/dagger is mounted using empty dir. πŸ€”

lean jackal
#

using rclone and tar on the docker compose is working fine

lean jackal
#

after seeing the log, righ bellow one of the pulled docker image, i see snapshoot are being removed. is that normal?

proper jewel
#

@lean jackal were you able to make progress here?

lean jackal
#

Hi @proper jewel , i ended up creating a new thread (which you already commented) since it no longer the problem with the experimental flag or cache restore. Thanks again

proper jewel
#

πŸ‘

calm hill
#

Sorry to bring this back up, but can you explain how to use _EXPERIMENTAL_DAGGER_CACHE_CONFIG? It's not in the docs anywhere