Epic: Bring Providers to Crossplane V2

[Lasserich]

Understand the Epic

Crossplane has released a new version which affects how our Providers operate. Let's collect steps needed to bring the BTP and Cloudfoundry Crossplane Provider to Crossplane V2.

•  Test compatibility Crossplane V2 with providers V1 -> Does not work, provider becomes unhealthy FailedCreateContainer
• Test compatibility Crossplane V1 with providers V2 -> Works after re-tries (tested with aws V2) --> Provider becomes healthy
• Test compatibility Crossplane V1 with providers V2 -> Test if MR (old clsuter-scoped and new namespace-scoped MR) become ready/sncyed
• How do we handle upgrades of all our community providers
• Exchange with OpenMCP Team on findings
• Map out Upgrade Path for upgrading a provider

Acceptance Criteria

• Know consequences of different upgrading approaches
• Commit to an upgrading path, with follow up items for BTP and CF providers
• Commit to an upgrading strategy for community providers

Out of scope

• Migrating Crossplane V2 on cluster scope with legacy provider -> responsibility of OpenMCP
• Migrate every Crossplane provider

References

•  [Spike] Run all Provider e2e tests on Crossplane v2 #186

[enrico-kaack-comp]

On the topic of upgrading the providers (updated with the final information of investigating into v2):

• crossplane-runtime v2 has a release, thats working in the petstore provider
• upjet v2 is not yet released, actively worked on in main (aws-upjet-provider is using it from a v2 tag) (needed for BTP provider, CF is upjet free)
• externalSecretStore feature (feature flag enabled) is not supported anymore --> we would remove this feature entirely
• providerconfig is now namespaced by default (might be an issue for migration, need to check), additionally new resource ClusterProviderConfig exist
• new namespace-scoped MRs would be introduced as separate type, not breaking old cluster-scoped resources and allow to run on crossplane v1 clusters (e.g. kubernetes-provider mentions in their release notes:

This provider can be installed in Crossplane v1.x environments:
Both cluster-scoped and namespace-scoped CRDs will be installed; namespace-scoped CRDs cannot be composed in v1.x.

• the namespace-scoped resources could be introduced step by step. The provider logic how these are handled should not change much. Unfortunately I havent found a good example on this yet. Kubernetes-provider simply copy&paste the controller coding for the new resources. This does not sound feasible for our resources. In the community call it was acknowledged that provider development guides are missing for the migration and they will work on some docs.

So in general we can break up this problem into two stages:
(1): upgrade the provider to v2 without introducing new namespaced reosurces. This is "basically" just bumping dependencies, removing externalSecretStore and changing some types. For upjet, this might be a bit more complicated. Also need to handle the providerconfig and ClusterProviderConfig.

The provider can be used o crossplane v2 but the new namespace-scoped resources cant be used yet.

(2): Introduce the new namespace-scoped MR as separate types that uses the same controller coding in the background. This is more effort to see how to do this in a clean way.

I think the cloud-foundry provider (doesnt use upjet) is probably easier to upgrade. The BTP provider with upjet and hybrid approach could be more effort.