Ability to specify minor version of Openshift
Component
Images
Is your enhancement related to a problem? Please describe
It would be very useful to have the ability to specify the version of Openshift instead of having to rely on a hard coded value in each build. I understand this might be difficult to support any version of Openshift, but even just having the ability to support minor versions would be helpful. For example, I want to keep testing on 4.18, but the latest 4.18 version is 4.18.2, which is old. If major versions (ie 4.18 and 4.19) are not possible, please consider minor versions.
Describe the solution you'd like
Having a new field in the configuration for which Openshift version to pull would solve this. For example, one could pass 4.18.17 or 4.19.1.
Describe alternatives you've considered
The only alternative is to hope a version of the CRC executable has the Openshift version you want, but that is unlikely. I want to keep testing on 4.18 but must an older z version of 4.18.2. I also tried upgrading but don't believe this is possible.
Additional context
No response
Check crc setup or crc start help. At any of this moments you can change the bundle to use:
$ crc setup --help
Set up local virtualization and networking infrastructure for using CRC
Usage:
crc setup [flags]
Flags:
-b, --bundle string Bundle path/URI - absolute or local path, http, https or docker URI (string, like 'https://foo.com/crc_libvirt_4.19.0_amd64.crcbundle', 'docker://quay.io/myorg/crc_libvirt_4.19.0_amd64.crcbundle:2.52.0' default '/home/alberto/.crc/cache/crc_libvirt_4.19.0_amd64.crcbundle' ) (default "/home/alberto/.crc/cache/crc_libvirt_4.19.0_amd64.crcbundle")
--check-only Only run the preflight checks, don't try to fix any misconfiguration
--enable-experimental-features Allow the use of experimental features
-h, --help help for setup
-o, --output string Output format. One of: json
--show-progressbars Always show the progress bars for download and extraction
Global Flags:
--log-level string log level (e.g. "debug | info | warn | error") (default "info")
if already downloaded you can use directly the filename:
$ la /home/alberto/.crc/cache/
total 22G
drwxr-xr-x. 1 alberto alberto 132 ene 21 15:38 crc_libvirt_4.17.10_amd64
-rw-rw-r--. 1 alberto alberto 5,2G ene 13 01:26 crc_libvirt_4.17.10_amd64.crcbundle
drwxr-xr-x. 1 alberto alberto 132 feb 24 21:24 crc_libvirt_4.17.14_amd64
-rw-rw-r--. 1 alberto alberto 5,3G feb 11 12:57 crc_libvirt_4.17.14_amd64.crcbundle
drwxr-xr-x. 1 alberto alberto 132 dic 13 2024 crc_libvirt_4.17.7_amd64
-rw-rw-r--. 1 alberto alberto 5,1G dic 6 2024 crc_libvirt_4.17.7_amd64.crcbundle
-rw-r--r--. 1 alberto alberto 12M may 6 12:40 crc_libvirt_4.18.12_amd64.crcbundle
-rw-rw-r--. 1 alberto alberto 5,8G mar 20 17:49 crc_libvirt_4.18.2_amd64.crcbundle
drwxr-xr-x. 1 alberto alberto 48 may 6 13:14 tmp-extract
tool will warn about usage of non default bundle:
$ crc setup -b crc_libvirt_4.17.10_amd64
WARN Using crc_libvirt_4.17.10_amd64.crcbundle bundle, but crc_libvirt_4.19.0_amd64.crcbundle is expected for this release
which may lead to unexpected behaviour, as we don't test backward bundles
Thank you for the reply, it looks like I can use the bundle flag to do what I need. Where can I get these bundle files to download? I am a Red Hat employee and I have my pull secret, where can I browse these bundle files to see what is available?
EDIT:
I was able to find the bundles listed below. Do you know the process of how new versions get added? 4.18.12 is much newer than 4.18.2 but still a little old. I'm curious how often this set of bundles is updated.
https://mirror.openshift.com/pub/openshift-v4/clients/crc/bundles/openshift/
Openshift version: https://openshift-release.apps.ci.l2s4.p1.openshiftapps.com/
I'm curious how often this set of bundles is updated.
For now, we usually update them once every 3 weeks or so.
Check https://crc.dev/blog/ for "Releases" section:
https://mirror.openshift.com/pub/openshift-v4/clients/crc/bundles/
These posts might be interesting:
https://crc.dev/blog/posts/2024-03-22-use-bundle-option/ https://crc.dev/blog/posts/2022-09-26-bundle-option-in-crc/
Thank you both for the replies. In regards to the bundles being updated, it looks like older version of OCP do not have any recent bundles. For example, for OCP 4.18, the latest bundle is 2 months old and for OCP 4.17, it's 5 months old. Several recent versions of OCP are still supported: https://access.redhat.com/support/policy/updates/openshift. I work as a QE engineer for the ACM installer team and frequently need to test with the various supported OCP versions and the minor version of OCP is very important to my testing.
Would it be possible to request more frequent updates, especially for the final version of a minor version of OCP? Or, is it possible for me as the end user to generate my own bundles from an OCP installation? If the latter is possible, could you please provide instructions?
We build a single node cluster from standard bundles:
https://github.com/crc-org/snc
Rebuild outside of existing releases may lead to unexpected behaviour, and we don't plan to provide support on past releases, but tecnically is possible. If problem arises, issue tracker might provide info about why some OCP versions where skipped, but in general, there will be dragons there
In the future, we will release bundles independently of CRC, as they will be self-contained/self-sufficient.
To have the bundles released independently would be a great enhancement.
As this is intended for testing, might I suggest generated bundles for more releases, including past OCP version that are still supported? The latest version of most OCP releases (included still supported ones) are quite old. As a QE tester myself, I often need a specific version of OCP and I must test on all supported OCP y versions, and ideally a recent z version. Providing bundles for such releases would be a huge help to all of us using this for testing purposes.
https://endoflife.date/red-hat-openshift
It is really intuitive to have bundles for every z release but testing/hosting/maintenance is a big issue. As of now all the bundles which are part of mirror is tested and approved by our QE folks and having every z stream bundle means a lot of work even we have most of the part automated. If we just publish untested bundle then where should we do that (internal server, who maintains it and how to get space because each release bundle occupy around 21G).
I think best way is to create your own bundles https://crc.dev/blog/posts/2023-06-05-create-okd-bundle store it and use it when it required. It would be much better if we have some kind of hardware where we can run bundle creation as service and anyone could create bundle for z stream and push somewhere internally to consume.
Thank you for the link, I did come across that in my research. However, those steps seem specific to OKD bundles, and I am using libvirt bundles (for example, crc_libvirt_4.18.12_amd64.crcbundle). Are there similar steps for generating that kind of bundle?
Thank you for the link, I did come across that in my research. However, those steps seem specific to OKD bundles, and I am using libvirt bundles (for example, crc_libvirt_4.18.12_amd64.crcbundle). Are there similar steps for generating that kind of bundle?
Steps are same just use the right pull secret instead the dummy one also try to use RHEL-9 as host which have proper resource.