Allow spec.json files to be clearsigned, use transparent compression for *.json#34490
Conversation
See spack#34491. Should go after spack#34490.
See spack#34491. Should go after spack#34490.
92bf8c8 to
f48b6ca
Compare
scottwittenburg
left a comment
There was a problem hiding this comment.
Looks great, thanks @haampie 👍
I just had one question, but feel free to merge regardless.
| local_specfile_stage.destroy() | ||
| # If it is a clearsign file, we must verify it (unless disabled) | ||
| should_verify = not unsigned and is_clearsigned_file(specfile_path) | ||
| if should_verify and not try_verify(specfile_path): |
There was a problem hiding this comment.
Hm, another issue is that this is not yet working, cause it's first clearsigned and then gzipped, so verification requires decompression. Should the order be reverted? Sign the compressed json?
There was a problem hiding this comment.
Went with compress(sign(json)) so that we can swap the compression scheme without the need to re-sign the files.
f48b6ca to
018ba60
Compare
Currently we have separate `spec.json` and `spec.json.sig` files. The former is a pure spec, the latter is clearsigned spec. This is a bit unfortunate, cause a lookup for a spec file now requires two remote requests (with or without cache). This PR allows clearsigned `spec.json` files too, and changes otherwise nothing. The idea is to backport this to 0.19.1, since for 0.19.1 it is not a behavioral change, but rather a bugfix for improved 0.20 / 0.21 forward compatibility. Next steps after this PR: - Start uploading spec.json.sig files both as spec.json.sig and spec.json. This ensure they work with any Spack version. - Deprecate spec.json.sig in 0.20. - After Spack 0.20 branches off, stop uploading *.sig, and stop checking the remote for *.sig files. - Potentially we can also add a config option to disable checking for *.sig files on develop earlier.
The files spec.json / spec.json.sig / index.json can now be stored gzip compressed (without .gz extension)
018ba60 to
6c20ec1
Compare
scottwittenburg
left a comment
There was a problem hiding this comment.
Looks good to my eyeballs 😆 thanks @haampie! I notice the past several gitlab pipelines haven't built anything (as expected), but since this isn't actually changing what we push (still pushing .spec.json.sig, not compressing them yet), this isn't likely to break anything when run in the wild. But it's good preparation for the next steps, thanks again 👍
…for *.json (spack#34490) This commit allows (remote) spec.json files to be clearsigned and gzipped. The idea is to reduce the number of requests and number of bytes transferred
…ression for *.json (spack#34490)" (spack#34856) This reverts commit 8a1b817.
…for *.json (spack#34490) This commit allows (remote) spec.json files to be clearsigned and gzipped. The idea is to reduce the number of requests and number of bytes transferred
…ression for *.json (spack#34490)" (spack#34856) This reverts commit 8a1b817.
…for *.json (spack#34490) This commit allows (remote) spec.json files to be clearsigned and gzipped. The idea is to reduce the number of requests and number of bytes transferred
…ression for *.json (spack#34490)" (spack#34856) This reverts commit 8a1b817.
…for *.json (spack#34490) This commit allows (remote) spec.json files to be clearsigned and gzipped. The idea is to reduce the number of requests and number of bytes transferred
…ression for *.json (spack#34490)" (spack#34856) This reverts commit 8a1b817.
This PR does two things:
It does not make any changes to how we create binary caches.
The idea is to allow this PR to be backported.
Currently we have separate
spec.jsonandspec.json.sigfiles. Theformer is a pure spec, the latter is clearsigned spec. This is unfortunate,
cause metadata lookups now requires at most two requests per remote.
Further, update-index logic fetches all spec.json files, which can take
quite some bandwidth. We can drop ~85% of the size by compressing
those files. To avoid yet another lookup (spec.json.sig.gz etc) we can
use transparent decompression. So a file is decompressed when the
magic bytes signal it's gzip, otherwise it's treated as text.
This PR allows
spec.json(andindex.json) files to be any combinationof the cartesian product
[gzip compressed, uncompressed]x[clearsigned, unsigned].The idea is to backport this to 0.19.1, since for 0.19.1 it is not a
behavioral change, but rather a bugfix for improved Spack 0.21 forward
compatibility.
Next steps after this PR:
spec.json. This ensure they work with any Spack version.
the remote for *.sig files.
*.sig files on develop earlier.