-
Epic
-
Resolution: Unresolved
-
Critical
-
None
Goal
Provide a network solution working out of the box, meeting expectations of a typical VM workload.
User Stories
- As an owner of a VM that is connected only to a secondary overlay network, I want to fetch resources from outside networks (internet).
- As a developer migrating my VMs to OCP, I do not want to change my application to support multiple NICs.
- My application needs access to a flat network connecting it to other VMs and Pods.
- I want to expose my selected applications over the network to users outside the cluster.
- I'm limited by public cloud networking restrictions and I rely on their LoadBalancer to route traffic to my applications.
- As a developer who defined a custom primary network in their project,
I want to connect my VM to this new primary network, so it can utilize it for east/west/north/south, while still being able to connect to KAPI.
Non-Requirements
- Service mesh integration is not a part of this
- Seamless live-migration is not a must
- UI integration is tracked in CNV-46603
Notes
- This epics tracks graduation of features previously developed upstream on OVN Kubernetes, and additional VM-specific work.
- Once we have both ingress and egress, we may be able to obsolete the custom solution on OVN-K introduced for HyperShift.
- From binding plugins epic:
- https://docs.google.com/document/d/1GZOxEh21TQilgnHULlVq0_6g0K8XKzZIItlZ_Yjv-x0/edit#heading=h.tv7nbn6fqsz2
- https://docs.google.com/document/d/1wt3z9EH5LKk02IQK7xlIxBbu-DSnw2jSgbnyYE96VDA/edit#heading=h.e9t0h9kcw91
- https://github.com/openshift/enhancements/pull/1623
- This could come in a form of a network binding. Passt should be used to allow integration with service meshes, while leveraging the L2 overlay for same IP inside and outside the guest
- There are two options how to implement this:
- Plug each individual Pod NIC as a VNIC to the guest
- Let Pod routing do its job and use Passt binding to connect the guest to it through a single VNIC
- Most likely this won't work with any existing core binding of KubeVirt - we will need to introduce our own binding plugin
- Leveraging passt would make it easier to create our plugin, since it already handles user-space networking for us and DHCP for the guest
- We could host the new binding plugin under the same repo as IPAM claims controller. Basic passt plugin template is available here: https://github.com/kubevirt/kubevirt/tree/main/cmd/cniplugins/passt-binding
- There was a presentation about binding plugins on KubeVirt Summit 2024
- Â
- blocks
-
MTV-1369 Support mapping to primary user-defined networks
- New
- clones
-
CNV-4600 CNV Epic Template
- New
- incorporates
-
CNV-24258 OVN Kubernetes: L2 overlay ingress
- Closed
-
CNV-33753 [DP] OVN Kubernetes: L2 overlay egress
- Closed
-
CNV-44224 [GA] OVN Kubernetes: L2 overlay egress
- Closed
- is blocked by
-
CNV-44344 [GA] Network binding plugin API
- Backlog
- is depended on by
-
CNV-48715 [TP] UDN Checkup
- New
-
CNV-46603 UI for OVN Kubernetes: Primary user-defined networks
- In Progress
- is related to
-
CNV-50056 [TP] OVN: Preview of user-defined primary networks in Virtualization
- New
- split from
-
CNV-47513 ipam-extensions: integrate with the UDN feature
- Closed
- split to
-
CNV-48487 PoC: specify IPAMClaim via multus default network annotation
- Closed
-
CNV-48488 PoC, OVN-K: provision DHCP / DHCPv6 / RA flows for virt workloads
- Closed
- links to
1.
|
upstream roadmap issue | New | Unassigned | ||
2.
|
upstream design | New | Unassigned | ||
3.
|
upstream documentation | New | Unassigned | ||
4.
|
upgrade consideration | New | Unassigned | ||
5.
|
CEE/PX summary presentation | New | Unassigned | ||
6.
|
test plans in polarion | New | Unassigned | ||
7.
|
automated tests | New | Unassigned | ||
8.
|
downstream documentation merged | New | Unassigned |