Support for multiple VM operator versions #3758
Description
/kind feature
Describe the solution you'd like
New versions of CAPV need to continue to work on older vSphere / supervisor versions.
This implies e.g. to be able to interact with VM operator's v1alpha2 API version when CAPV is running on vSphere 8.x, while instead using VM operator's v1alpha5 API version on newer vSphere versions.
Tracking issue
- Start testing with vm operator v1.9 🌱 Start testing with VM operator v1.9 #3756
- Introduce support for multiple VM operator versions
- Create all the required machinery, change production code to use it, but still use v1alpha2 to ensure no-regression happens ✨ Add support for multiple supervisor versions #3767
- Change production code to use v1alpha5, change unit test to use v1alpha5 ✨ Switch from vm-operator v1alpha2 API to v1alpha5 #3784
- Introduce the dynamic switch from v1alpha2 to v1alpha5 + E2E test for both scenarios ✨ Dynamically choose API version for vm-operator #3812 Add E2E tests for CAPV supervisor versions kubernetes/test-infra#36328
- Other
- Add a unit test ensuring fields of type list in the hub version have all the sub-fields existing in native types 🌱 Implement type check for hub types #3801
- pick up the govc version after v0.52.0 as soon as available, drop tmp change in Makefile 🌱 Start testing with VM operator v1.9 #3756 (comment)
- pick up the new vmoperator version as soon as available and start using it for testing as well
- improve ensurefinalizer util in CAPI to avoid usage of the patch helper and drop the CAPV "fork" 🌱 Start testing with VM operator v1.9 #3756 (comment)