crc versioning strategy and/or easier installer unpacking?

[KevinMGranger]

Questions

1. Can distributing crc on Windows be made simpler for CLI usage?
2. Are there broader discussions on managing OpenShift versions with crc?
3. If version management is something I can accomplish, is this something y'all would want integrated with crc?

If this is an XY problem, switching between OpenShift versions is the X, and unpacking the installer is the Y.

Background

I'm working on a crc version manager, so that one can easily switch between OpenShift versions for local testing.

Since the bundle versions are more or less linked to the crc executable version, I have to automate installing crc itself.

While this is trivial on Linux and MacOS, it's harder on Windows, which is what I'm targeting for now. I can't find many cab file libraries.

[gbraad]

I'm working on a crc version manager, so that one can easily switch between OpenShift versions for local testing.

We already consider moving to a way to use crc with different bundle versions. For this debundling has been performed which will soon be merged into our master.

This means that during the setup of crc we will download the bundle from the CDN or use a cached version. The actual crc release will be much smaller; though it will include the installer and the new desktop application.

Note: command line use is still possible

[KevinMGranger]

Does this mean that an upcoming crc release will support arbitrary bundle versions, or is there a limit to what can be supported? I see the comment about certificate rotation. I'm don't understand if that limits this, or if that just means worse UX once the cert expires.

[gbraad]

support arbitrary bundle versions

Not yet, and most likely only for a limited set of version options. The support depends on the additional changes we need to add to create a SNC. While work has been done to create a Single Node from the OpenShift engineering side, some gotchas still happen.

certificate rotation

either adds startup time or the cluster might not come up. We try to test this procedure for each release but it is time consuming. We haven't come back in time to verify versions, though we know for sure some won't work. This is also why the installation is not performed from the vscode plugins anymore, as they initially wanted to provide a similar version management option. At that time we disallowed this usecase as it would add more work on our end as it is expected 'we support this'.

[gbraad]

• Let users use custom images (other ocp version, with customization) #718

[gbraad]

@KevinMGranger we will consider delivering crc binaries for Windows again, plus there are some other thoughts around this. It might be test to talk to you about this. Either we have a solution for you... or you can convince us what we can modify to make your life easier.

[gbraad]

Can distributing crc on Windows be made simpler for CLI usage?

At the moment the installer is necessary to setup the requirements. these are enforced by the crc start command as part of preflights. however, the command crc setup deals with most of the automation you are looking for.

We are in the process to eventually move the installer to a new repo, which makes the release of crc a regular binary drop. -> crc-org/tray-electron#91

[KevinMGranger]

What I mean is quite literally getting the installer out of the cab files. Once the installer work you mentioned is finished, that will work-- but only if version management is integrated like you said above.

[gbraad]

cabextract, but that would only be a part of the installation. the parts performed by the MSI: https://github.com/code-ready/crc/tree/master/packaging/windows would only wok from the MSI :-P.

By unpacking the msi you will have a crc-binary with an embedded bundle. This is about 2.2G in size. You can use this with crc setup to extract and use. but this is not a tested scenario at the moment as this is not how we run it.

[KevinMGranger]

I can run the msi from the cli. I didn't see cabextract before!

This sounds like it'll work for my use case across arbitrary versions. Thank you!

[gbraad]

Are there broader discussions on managing OpenShift versions with crc?

Yes. as the goal is to allow a range of version, like 4.9 with a certain crc binary, and 4.10 with a follow-up perhaps. these are ongoing discussions. currently we have focused more on the debundling process and offering podman.

[gbraad]

If version management is something I can accomplish, is this something y'all would want integrated with crc?

We might consider. Although the biggest pain point is the testing. We run automated and manual tests for each release to make sure the cluster can be brought up in a usable state.

One of the biggest pain points will however remain the 'certificate rotation'. This process kicks in after 30 days of the bundle release and cause additional time during the startup or in the worst case, a failing cluster. This is why we only support the current release. When people are using a previous version we always ask them to upgrade as we can not provide backports or fixes for older bundles.

[KevinMGranger]

30 days from the bundle release, not 30 days from when the cluster is first set up? Is there some way to manually work around it that I could try?

[gbraad]

The bundle/cluster creation is the same date. If the cluster was restarted before, running or regenerated with crc bundle generate additional time is added as there is a sliding window that causes a rotation. At the moment there is no way for us to force a new certificate rotation besides what we offer, but that adds about 5+ minutes to the startup for older releases.

[KevinMGranger]

I'm okay with longer startup times for my use case, as switching would be relatively infrequent.