Skip to content

🌱 vsphereparavirtual: Support multiple VM Operator API versions#1713

Open
silvery1622 wants to merge 1 commit intokubernetes:masterfrom
silvery1622:support-multi-vmop-version
Open

🌱 vsphereparavirtual: Support multiple VM Operator API versions#1713
silvery1622 wants to merge 1 commit intokubernetes:masterfrom
silvery1622:support-multi-vmop-version

Conversation

@silvery1622
Copy link
Copy Markdown
Collaborator

@silvery1622 silvery1622 commented Mar 18, 2026

What this PR does / why we need it:
Introduce a version-agnostic Hub Type / Hub Interface layer so that CPI business logic is decoupled from any specific VM Operator API version. The correct versioned adapter is selected at startup via the --vm-operator-api-version flag, enabling backward compatibility with Supervisor while supporting v1alpha5.

Which issue this PR fixes (optional, in fixes #(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
N/A — new feature

Special notes for your reviewer:

  • The CPI only uses a small subset (~10-15 fields) of the VM Operator API. Hub Types are intentionally minimal.
  • The v1alpha2 adapter preserves exact behavioral equivalence with the previous typed-client implementation.
  • dynamic.Interface is used instead of typed clients to avoid importing the full VM Operator API scheme into the CPI binary for each supported version.
  • The CPI never creates, updates, or deletes VirtualMachine objects. It only reads them for node discovery. Both the v1alpha2 and v1alpha5 VM clients expose only Get and List.

Release note:
vsphereparavirtual: add --vm-operator-api-version flag (default: v1alpha2) to select the VM Operator API version used when communicating with the Supervisor cluster. Supported values: v1alpha2, v1alpha5.

@k8s-ci-robot k8s-ci-robot requested review from chenlin07 and wyike March 18, 2026 09:50
@k8s-ci-robot
Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: silvery1622

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Mar 18, 2026
@silvery1622
Copy link
Copy Markdown
Collaborator Author

/hold

@k8s-ci-robot k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Mar 18, 2026
@silvery1622 silvery1622 force-pushed the support-multi-vmop-version branch 3 times, most recently from 040ec69 to 4267c7e Compare March 19, 2026 02:20
@silvery1622
Copy link
Copy Markdown
Collaborator Author

/test pull-cloud-provider-vsphere-verify-fmt

@silvery1622 silvery1622 force-pushed the support-multi-vmop-version branch 2 times, most recently from 2db282c to 403a692 Compare March 23, 2026 01:36
@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 23, 2026
@silvery1622 silvery1622 force-pushed the support-multi-vmop-version branch 3 times, most recently from 97faa77 to 1e77192 Compare March 24, 2026 05:31
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 24, 2026
…a2, v1alpha5)

Introduce a version-agnostic Hub Type / Hub Interface layer so that CPI
business logic is decoupled from any specific VM Operator API version.
The correct versioned adapter is selected at startup via the
--vm-operator-api-version flag, enabling backward compatibility with Supervisor
while supporting v1alpha5.
@silvery1622 silvery1622 force-pushed the support-multi-vmop-version branch from 1e77192 to 5ea0ae4 Compare March 24, 2026 05:36
Copy link
Copy Markdown
Collaborator

@DanielXiao DanielXiao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems massive code duplication between v1alpha2 and v1alpha5 adapters and providers, is it possible to a use shared generic helper package? In case we need to onboard v1alpha6, we need to implement the same duplicated code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants