Remove Validation for using a different version of bundle for a specific CRC release

[praveenkumar]

As of now, each CRC release is tied to a specific version of bundle and if user try to use different version of bundle with release bit then we don't allow it (error out) using https://github.com/code-ready/crc/blob/main/pkg/crc/validation/validation.go#L58-L80 block of code.

With one of the discussion with @veillard, he prefer we should remove that restriction and show a user warning if using a different version of bundle then what we ship for a specific release, something like our dev bits. This issue is to discuss it and prioritize the required work.

It has been around 3 years since we are shipping crc with pinned version and also we create bundles during dev cycle but most of the time we dont' upload all of them but only the one which would be part of crc release so with this suggested change we are able to only release the bundle once it is tested with specific version of crc even delaying a crc release. During this period we also didn't a lot of user creating their own bundle and using it with CRC so I am assuming 95% user only consume the bundles which we deliver and go with it.

[cfergeau]

This will also be required by the work being tracked in https://github.com/code-ready/crc/issues/3206

Fwiw, https://github.com/code-ready/crc/blob/main/pkg/crc/validation/validation.go#L58-L80 has been partially broken for a long while. In https://github.com/code-ready/crc/blob/e6985c75486b219d1b29537d2e3ab12dc6e68d79/pkg/crc/validation/validation.go#L82-L90 , if the user request a bundle version which is already unpacked in ~/.crc/cache/ then we'll never call ValidateBundlePath and we'll consider the bundle valid.

In upgrade scenarios, this means a newer crc release can start older bundles that were unpacked by previous releases. And the only step required for an older release to use a newer bundle is to unpack the bundle manually.

[praveenkumar]

Fwiw, https://github.com/code-ready/crc/blob/main/pkg/crc/validation/validation.go#L58-L80 has been partially broken for a long while, if the user request a bundle version which is already unpacked in ~/.crc/cache/ then we'll consider it valid. In upgrade scenarios, this means a newer crc release can start older bundles. And the only step required for an older release to use a newer bundle is to unpack the bundle manually.

@cfergeau you mean something like following works in release bits?

• Manually download 4.11.1 bundle and extract it to ~/.crc/cache
• Then use crc 2.7.1 release bits to start it with -b <path_to_4.11.1>

[cfergeau]

Fwiw, https://github.com/code-ready/crc/blob/main/pkg/crc/validation/validation.go#L58-L80 has been partially broken for a long while, if the user request a bundle version which is already unpacked in ~/.crc/cache/ then we'll consider it valid. In upgrade scenarios, this means a newer crc release can start older bundles. And the only step required for an older release to use a newer bundle is to unpack the bundle manually.

@cfergeau you mean something like following works in release bits?

* Manually download 4.11.1 bundle and extract it to `~/.crc/cache`

* Then use crc 2.7.1 release bits to start it with `-b <path_to_4.11.1>`

I tested with bundles older than 2.7.1 which were already unpacked, and yes this was working. I think the steps you describe would also work fine, but that's totally unintended.

[cfergeau]

Are we going to remove this code altogether? Or are we going to check that the bundle version is 4.11.x, with x greater than what the crc binary was released with? We need to remember to maintain bundle versioning when we make non-compatible changes, see https://github.com/code-ready/snc/blob/3d5d3a2ac849dbc9a875f741a728559c7225a0b1/crc-bundle-info.json.sample#L2-L11 and https://github.com/code-ready/crc/blob/e6985c75486b219d1b29537d2e3ab12dc6e68d79/pkg/crc/machine/bundle/repository.go#L67-L82

[praveenkumar]

Are we going to remove this code altogether? Or are we going to check that the bundle version is 4.11.x, with x greater than what the crc binary was released with?

@cfergeau I would first go with second option (just check bundle version is different (no greater or smaller) than what we release crc binary with) and add a warning or do we want to put a restriction on using only greater version?

[stale[bot]]

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.