applying pre k8s 1.2.1 bundles to 1.21+ clusters

[ankitathomas]

When applying CRDs from unpacked bundles, rukpak doesn't convert the CRD version to match apiVersion supported by the underlying cluster.

If a bundle image has a CRD with {apiVersion: [apiextensions.k8s.io/v1beta1], kind: CustomResourceDefinition} and the cluster supports the apiVersion {apiVersion: [apiextensions.k8s.io/v1], kind: CustomResourceDefinition}, rukpak tries to apply the CRDs directly, failing with no matches for kind \"CustomResourceDefinition\" in version \"[apiextensions.k8s.io/v1beta1]\"\nensure CRDs are installed first

some affected bundles:
"quay.io/openshift-community-operators/kiali@sha256:cb01816226cc731c8c35f6d0643447468dfa3db4bb6132320e9dc2bba1ce5c66"
"quay.io/openshift-community-operators/prometheus@sha256:6fbd3eaa123054c5023323d1f9ab7cbea178087fcb7cb4f3e83872c6a88d39a1"
"quay.io/openshift-community-operators/redis-operator@sha256:b8ab4fcdbef94394b6126857e40eecbadf700da0b123ced37af5902471ecae8e"

[joelanford]

I might be able to be persuaded, but I think my stance is that Rukpak, in general, should not do any "magic" like this. If a bundle contains an object that is not supported by the API server, I'd expect a failed installation and a message in the BD status that says what object/gvk could not be applied due to api not existing on the cluster.

If we do conversion for CRDs, that sort of sets the precedent that we'll do conversion for other types. That's not a road we should go down IMO.

I'd also call this a feature request, not a bug.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.