crc
crc copied to clipboard
[Bundle] Downloads the bundle or show bundle URI for external tooling
Use case
- If a user want to use crc in disconnect environment then from 2.0.1 he/she need to download the crc binary and also the bundle and the do something following to download the bundle.
$ openshiftVersion=$(curl -sL https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/release-info.json | jq -r .version.openshiftVersion)
$ curl -L -O https://mirror.openshift.com/pub/openshift-v4/clients/crc/bundles/openshift/"${openshiftVersion}"/crc_libvirt_"${openshiftVersion}"_amd64.crcbundle
- As of now bundle is downloaded as part of setup and cli side user get nice progress bar around download but when it is done by tray or any other tool (in future) then as of now there is no json streaming ( #2935 to track this work) So it would be better to have it handled by the tool itself if url and required checksum is provided.
Purpose:
Extend the bundle
command to provide the url for different preset for different platform which contain the shasum to validate the bundle checksum.
$ crc bundle url
{ "amd64": {
"darwin": {
"openshift": {
"uri": "https://mirror.openshift.com/pub/openshift-v4/clients/crc/bundles/openshift/4.10.3/crc_hyperkit_4.10.3_amd64.crcbundle",
"checksum": "57c8adae49beeb83d7a180aaba962256c2833863e1f59492295841a3e6e3f016",
}
}
}
...
Also have $ crc bundle download
command to download the bundle for that platform for specified preset or we can also have preset and distro as options to this command to download different preset bundle on different platform if user needed it.
crc bundle download
would provide progress through the http API, and ideally the same code could be reused for download during crc setup
to have progress there too (or maybe this would only be supported in download).
crc bundle download
will download the bundle to ~/.crc/cache
, and will also check its checksum. Not sure whether it should also do the decompression or not?
In crc bundle url
, sha256sum
rather than checksum
is going to be more future-proof in case we ever need to change the checksum algorithm. Though at worse we can add a prefix to the checksum
to identify it.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.