-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add possibility to download IPFS images #2408
base: master
Are you sure you want to change the base?
Conversation
The lima.yaml would then look something like: - location: "ipfs://QmUy3RRqbpsxXYQ7yp4h2koFHdGdVTCfRiqCBLkw1JobUK/ubuntu-24.04-server-cloudimg-amd64.img"
arch: "x86_64"
digest: "sha256:32a9d30d18803da72f5936cf2b7b9efcb4d0bb63c67933f17e3bdfd1751de3f3" (the file name is only used for decompression) Note that the CID digest is not the file digest: https://cid.ipfs.tech/#QmUy3RRqbpsxXYQ7yp4h2koFHdGdVTCfRiqCBLkw1JobUK https://docs.ipfs.tech/concepts/content-addressing/#cids-are-not-file-hashes (small detail: |
Note: the ipfs tool will output v0 by default, unless using v0: QmUy3RRqbpsxXYQ7yp4h2koFHdGdVTCfRiqCBLkw1JobUK $ ipfs add --cid-version 0 ubuntu-24.04-server-cloudimg-amd64.img
added QmUy3RRqbpsxXYQ7yp4h2koFHdGdVTCfRiqCBLkw1JobUK ubuntu-24.04-server-cloudimg-amd64.img
453.00 MiB / 453.00 MiB [=================================================================================================================] 100.00%
$ ipfs add --cid-version 1 ubuntu-24.04-server-cloudimg-amd64.img
added bafybeig5sch22ecfox7gq724rz7uivydwvnnpuqdcnjz72iwelgtrakzui ubuntu-24.04-server-cloudimg-amd64.img
453.00 MiB / 453.00 MiB [=================================================================================================================] 100.00% The CID version doesn't really matter to Lima, but CIDv0 is deprecated. https://docs.ipfs.tech/concepts/content-addressing/#cid-versions |
Using
So now IPFS address looks the same as HTTP address, with "description":
Instead of the output that you get from
|
At first I was thinking that calculating the digest was unnecessary, since it already has one included in the storage. But we still want to compare the download with the digest we are expecting, to make sure it's the same image... |
Looks good, but needs a documentation |
There is a design flaw with this approach. Currently it would look like: - location: "https://cloud-images.ubuntu.com/releases/24.04/release-20240423/ubuntu-24.04-server-cloudimg-amd64.img"
arch: "x86_64"
digest: "sha256:32a9d30d18803da72f5936cf2b7b9efcb4d0bb63c67933f17e3bdfd1751de3f3"
- location: "ipfs://QmUy3RRqbpsxXYQ7yp4h2koFHdGdVTCfRiqCBLkw1JobUK/ubuntu-24.04-server-cloudimg-amd64.img"
arch: "x86_64"
digest: "sha256:32a9d30d18803da72f5936cf2b7b9efcb4d0bb63c67933f17e3bdfd1751de3f3" That means the checksum is duplicated, between the transports. Maybe: - location: "https://cloud-images.ubuntu.com/releases/24.04/release-20240423/ubuntu-24.04-server-cloudimg-amd64.img"
arch: "x86_64"
digest: "sha256:32a9d30d18803da72f5936cf2b7b9efcb4d0bb63c67933f17e3bdfd1751de3f3"
cid: QmUy3RRqbpsxXYQ7yp4h2koFHdGdVTCfRiqCBLkw1JobUK Note: The CID can be calculated, without adding the image to the disk store: $ sha256sum ubuntu-24.04-server-cloudimg-amd64.img
32a9d30d18803da72f5936cf2b7b9efcb4d0bb63c67933f17e3bdfd1751de3f3 ubuntu-24.04-server-cloudimg-amd64.img
$ ipfs add --only-hash --quieter ubuntu-24.04-server-cloudimg-amd64.img
QmUy3RRqbpsxXYQ7yp4h2koFHdGdVTCfRiqCBLkw1JobUK |
Unfortunately, Content-Type and Last-Modified are not provided by IPFS... Current gateway only use heuristics like file magic and relative freshness. Note: new implementations are supposed to use CID version 1 (not version 0): $ ipfs add --cid-version=1 --only-hash --quieter ubuntu-24.04-server-cloudimg-amd64.img
bafybeig5sch22ecfox7gq724rz7uivydwvnnpuqdcnjz72iwelgtrakzui |
41dc704
to
68fadb5
Compare
Currently it assumes that IPFS Kubo is set up. i.e. that https://docs.ipfs.tech/how-to/kubo-basic-cli/ This might also want to mention some experimental features, like using private networks: https://github.com/ipfs/kubo/blob/v0.30.0/docs/experimental-features.md#private-networks For testing purposes, you can use See also docs at: https://github.com/containerd/stargz-snapshotter/blob/main/docs/ipfs.md |
Could also add support for https://blog.ipfs.tech/ipfs-uri-support-in-curl/ If set, it would rewrite any
|
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
be4e62f
to
f63bd86
Compare
@@ -299,6 +299,10 @@ rosetta: | |||
# 🟢 Builtin default: use name from /etc/timezone or deduce from symlink target of /etc/localtime | |||
timezone: null | |||
|
|||
# Allow using IPFS for downloading files with a provided CID. | |||
# 🟢 Builtin default: false | |||
ipfs: null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just use location: cid://<CID>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or location: ipfs://<CID>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use ipfs: instead of https:, but then it becomes a different URL...
(which is bad because it would require multiple digests, and cache entries)
Also it would make it mandatory to use ipfs (or a ipfs gateway), to download?
By having it as an attribute on the File, it is possible to have it optional (and share digest)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That means the checksum is duplicated, between the transports.
I think this is better than introducing more YAML fields?
Also it would make it mandatory to use ipfs (or a ipfs gateway), to download?
The downloader should just fall back to the next candidate in the []Images
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is possible to do this with the current implementation, i.e. it supports both ways
You can change the location (url), or you can provide a cid for an existing location
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the fields are optional, they should not interfer so much with existing templates?
Probably want to have some more automation / sharing in place, before adding them.
Regarding addressing of ipfs objects, there are some more details here: "The four stages of the upgrade path for path addressing."
So it is simpler to only provide the CID/hash, as additional information? Since it is a multiformat/multihash, it doesn't need an additional prefix*. * it actually already has a couple of them, but in a string encoded form
|
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
More user-facing documentation (for the website) can go in a second PR. Maybe just use the links above? https://docs.ipfs.tech/how-to/kubo-basic-cli/ Also needs documentation on how to update images, then again we don't have any docs for sha256 either... - location: https://github.com/containerd/nerdctl/releases/download/v1.7.6/nerdctl-full-1.7.6-linux-amd64.tar.gz
arch: x86_64
digest: sha256:2c841e097fcfb5a1760bd354b3778cb695b44cd01f9f271c17507dc4a0b25606
cid: bafybeieipdaxd3fzy3j7syzzxdaqxramk65j7ajzcqgmi6b5jyq4jgbwue Like, when updated to 1.7.7 - how do you update the other fields? $ wget https://github.com/containerd/nerdctl/releases/download/v1.7.7/nerdctl-full-1.7.7-linux-amd64.tar.gz
...
HTTP request sent, awaiting response... 200 OK
Length: 259844835 (248M) [application/octet-stream]
Saving to: ‘nerdctl-full-1.7.7-linux-amd64.tar.gz’
$ sha256sum nerdctl-full-1.7.7-linux-amd64.tar.gz
a731eac93e8e9dda1a0d76dc1606438deb0668ea7d6bd5c5af436353ed9f65c5 nerdctl-full-1.7.7-linux-amd64.tar.gz
$ ipfs add --only-hash --cid-version=1 --progress=false nerdctl-full-1.7.7-linux-amd64.tar.gz
added bafybeiexmdvas4d3dy3npvecj3udihifaqndhelpiyjb67zbsm3g5eqlba nerdctl-full-1.7.7-linux-amd64.tar.gz |
See https://docs.ipfs.tech/how-to/kubo-basic-cli/ for
ipfs
https://docs.ipfs.tech/how-to/address-ipfs-on-web/#native-urls
ipfs://{cidv1}/path/to/resource
(see also https://cid.ipfs.tech/)Closes #2407