VEP 41: Including external resources into Object Graph

[Alvaro Romero]

Hi all,

I’d like to bring attention to a follow-up PR [1] I opened to update VEP 41 with some requirements around handling external dependencies.

Quick recap: the Object Graph is meant to be a single source of truth listing all the objects a VM depends on. This is important for things like backup/restore or migration, where missing a dependency can easily cause failures or force users to build their own custom graph. Right now, the implementation only includes the main kubevirt and k8s resources. But there are also critical dependencies that live outside of Kubevirt (for example NADS or IPAM claims), which are still essential for VM functionality in scenarios like cross-cluster live migration.

We’ve talked about this in several meetings, and there’s still disagreement about whether kubevirt/kubevirt should know about these external resources. One suggestion has been to move the graph outside of Kubevirt, but we think that goes against the original VEP decision to keep it authoritative inside the project.

To address this, I opened this follow-up PR [1] to define clear conditions for when an external resource qualifies for inclusion in the graph:

• it’s directly relevant to a VM/VMI operation we support (e.g. cross-cluster live migration)
• it’s either explicitly referenced in the VM spec (like NADs) or defined by a KubeVirt-owned project (like IPAMClaims from ipam-extensions)
• it’s discoverable in a reliable and consistent way (by kubevirt-defined labels)
• If needed, it's accessed dynamically as an unstructured object (so no external imports required)
• the logic stays limited to the graph code itself without affecting into the rest of kubevirt.

I believe we can find a middle ground between keeping kubevirt free of unnecessary knowledge of other projects and still including minimal awareness of the external resources that are required for supported operations. This kubevirt PR [2] shows how this works in practice.

I also think it’s worth mentioning that kubevirt already has awareness of external dependencies today and this will always be the case to some extent. Rather than rejecting these proposals outright, it’s more productive to define what’s acceptable and where to draw the line. That’s what the VEP update is trying to achieve in some way.

Curious to hear your thoughts, and feel free to add feedback directly in the VEP.

[1] https://github.com/kubevirt/enhancements/pull/78
[2] https://github.com/kubevirt/kubevirt/pull/15186

[Edward Haas]

On Mon, Aug 25, 2025 at 6:49 PM 'Alvaro Romero' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

Hi all,

I’d like to bring attention to a follow-up PR [1] I opened to update VEP 41 with some requirements around handling external dependencies.

Quick recap: the Object Graph is meant to be a single source of truth listing all the objects a VM depends on. This is important for things like backup/restore or migration, where missing a dependency can easily cause failures or force users to build their own custom graph. Right now, the implementation only includes the main kubevirt and k8s resources. But there are also critical dependencies that live outside of Kubevirt (for example NADS or IPAM claims), which are still essential for VM functionality in scenarios like cross-cluster live migration.

We’ve talked about this in several meetings, and there’s still disagreement about whether kubevirt/kubevirt should know about these external resources. One suggestion has been to move the graph outside of Kubevirt, but we think that goes against the original VEP decision to keep it authoritative inside the project.

To address this, I opened this follow-up PR [1] to define clear conditions for when an external resource qualifies for inclusion in the graph:

• it’s directly relevant to a VM/VMI operation we support (e.g. cross-cluster live migration)

VM/VMI operation depends on which functionality is integrated with it, some are direct in the project and some are extensions. The extension dependency cannot be managed IMO by the core project. If the cross-cluster operation is fully implemented inside the kubevirt core project, then it makes sense. if it includes extensions, then I would claim it does not fit. 

• it’s either explicitly referenced in the VM spec (like NADs) or defined by a KubeVirt-owned project (like IPAMClaims from ipam-extensions)

NADs are indeed borderline here, they are ref by name. I can claim that it is not direct, but this is a bit weak.
Regarding "a KubeVirt-owned project" , especially IPAMClaim, it is a pure extension, it was intentionally designed so Kubevirt will not know about it. Asking for Kubevirt to be aware of all its possible extensions is unmaintainable IMO.

In practice, these extensions are added, removed and changed without Kubevirt being aware of it. So it is not practical IMO for the project to track it

in the context of the core component.

• it’s discoverable in a reliable and consistent way (by kubevirt-defined labels)
• If needed, it's accessed dynamically as an unstructured object (so no external imports required)
• the logic stays limited to the graph code itself without affecting into the rest of kubevirt.

I believe we can find a middle ground between keeping kubevirt free of unnecessary knowledge of other projects and still including minimal awareness of the external resources that are required for supported operations. This kubevirt PR [2] shows how this works in practice.

I also think it’s worth mentioning that kubevirt already has awareness of external dependencies today and this will always be the case to some extent.

Indeed, we have several cases like this which are making the maintenance of the project challenging.

The project reached a level of stability which we want to preserve, that includes its proper decoupling and isolation.

Rather than rejecting these proposals outright, it’s more productive to define what’s acceptable and where to draw the line. That’s what the VEP update is trying to achieve in some way.

I think that the feedback in previous attempts has been done after careful thought with detailed reasoning.

An alternative has been suggested to allow the needed functionality to be served.

Curious to hear your thoughts, and feel free to add feedback directly in the VEP.

Kubevirt is a self-contained project with several extended capabilities. Its extensions are optional and in their ideal state, invert the dependency.

By inversion, I mean that the core Kubevirt project is not aware directly about the extensions (e.g. IPAMClaims).

The extension can change freely without involving the core project, making the ecosystem around Kubevirt dynamic and less strict.

Adding logic in the project about these extensions has a maintainability burden. It also has a cost on the extensions, as they need to depend on the core project which is 1) stricter and 2) slower in terms of accepting changes and releasing them. 

I can just give an example: The dependency on the IPAMClaim is completely dependent on that project implementation. The implementation may add or remove things, including the CRDs, it is not a Kubevirt thing to care about.

I can only suggest for the VEP to include all possible design solutions and try to reason the pros and cons of each.

[1] https://github.com/kubevirt/enhancements/pull/78
[2] https://github.com/kubevirt/kubevirt/pull/15186

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/0351b424-3769-4953-abd2-a1867a49b228n%40googlegroups.com.

[Alvaro Romero]

Following yesterday's discussion during sig-compute, I've created a meeting to discuss this follow-up and either agree on merging or decide to close the PR before the upcoming VEP freeze.

Feel free to attend if interested. Link.

Current scheduled time is Tuesday, 2 September, 16:00–16:30 CEST (14:00–14:30 UTC). Feel free to propose a different time if necessary, thanks!