support local cache exporter and importer#615
Conversation
|
With the current solution if we don't use specific refs we need to pull all the cache metadata every time (a big json structure). I'm not sure if this could cause scaling issues here yet but if we would switch the backend from files to some highly available cache service that is exposed to multiple users we would probably need a solution for that. I'm ok with making |
|
@AkihiroSuda What are the next steps for this? |
|
|
Any thought about CSV? |
|
Not strictly against csv but seems incompatible with the other flags of buildctl eg. |
|
Can we deprecate e.g.
|
Yes, shouldn't be a problem. |
|
Sorry for delay, I'll try to work on next month |
d84ea44 to
793fe1a
Compare
e3d533f to
f59455f
Compare
|
Implementation is WIP but CLI and API are ready to review. |
77c8143 to
f1615d8
Compare
1d1684b to
1b87099
Compare
51912eb to
a49a1a5
Compare
|
updated PR with support for |
c45cf8d to
1fea4ae
Compare
|
Updated: now |
1fea4ae to
111a38f
Compare
| } | ||
|
|
||
| func testBasicCacheImportExport(t *testing.T, sb integration.Sandbox) { | ||
| func testBasicCacheImportExport(t *testing.T, sb integration.Sandbox, cacheOptionsEntry CacheOptionsEntry) { |
There was a problem hiding this comment.
possible follow-up: we need to update this test(or add a new one) to include local sources. Currently not testing a lot of the exporter/cachekeys code.
| * `mode=min` (default): only export layers for the resulting image | ||
| * `mode=max`: export all the layers of all intermediate steps | ||
| * `ref=docker.io/user/image:tag`: reference for `registry` cache exporter | ||
| * `store=path/to/output-dir`: directory for `local` cache exporter |
There was a problem hiding this comment.
why isn't tag (or name) a supported import/export option for local?
32a3b1a to
aad7b22
Compare
|
updated |
aad7b22 to
6bbf0cd
Compare
Export: $ buildctl build ... --export-cache type=local,store=/path/to/output-dir Import: $ buildctl build ... --import-cache type=local,store=/path/to/input-dir Impact on CLI: * Old (deprecated but still effective): `--export-cache localhost:5000/myrepo:buildcache --export-cache-opt mode=max` * New: `--export-cache type=registry,ref=localhost:5000/myrepo:buildcache,mode=max` Impact on API: * New fields are added to control.proto and gateway.proto. The daemon internally translates old API calls to the new ones. * While new API can be used for `registry` caches, the client continues to use the legacy API for `registry` caches to ensure compatibility with old daemons. * To import `local` caches with a frontend, the frontend needs to support a new frontend opt `cache-imports`. Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
|
updated |
6bbf0cd to
6e7617e
Compare
index.jsonSolver: define build caps(do we need caps?)Impact on CLI
--export-cache localhost:5000/myrepo:buildcache --export-cache-opt mode=max--export-cache type=registry,ref=localhost:5000/myrepo:buildcache,mode=maxImpact on API
control.protoandgateway.proto. The daemoninternally translates old API calls to the new ones.
registrycaches, the client continues to use the legacy API forregistrycaches to ensure compatibility with old daemons.localcaches with a frontend, the frontend needs to support a new frontend optcache-imports.Usage
To/From registry
To/From local filesystem