XML

Word

Printable

Epic Name:
cnv-ovn-k-multi-services
Acceptance Criteria:
Hide

D/S test automation

D/S documentation covering this as one of the Service examples

VMs and Pods can access each other using a Service defined over a secondary OVN Kubernetes network

VMs can be accessed through NodePort and LoadBalancer services over a secondary OVN Kubernetes network

Services stay connected during live-migration of a VM
Show
D/S test automation D/S documentation covering this as one of the Service examples VMs and Pods can access each other using a Service defined over a secondary OVN Kubernetes network VMs can be accessed through NodePort and LoadBalancer services over a secondary OVN Kubernetes network Services stay connected during live-migration of a VM
Current Status:
Red
Epic Status:
To Do
Feature Link:
CNV-16692 - OVN Secondary Network
Parent Link:
CNV-16692OVN Secondary Network
Status Summary:

Hide

2024-03-06: Copying Miguel's update: This is not looking good; while we've had successful engagements w/ the SDN team and NVIDIA (they're both interested in this feature - and that's a first ...), everybody has different requirements they want to cov...

Show
2024-03-06: Copying Miguel's update: This is not looking good; while we've had successful engagements w/ the SDN team and NVIDIA (they're both interested in this feature - and that's a first ...), everybody has different requirements they want to cov...
Target Version:

CNV v4.18.0

Goal

Productize native support of Services on secondary OVN Kubernetes networks.

User Stories

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.

This epic is not aiming at communication between different networks on the same cluster. Or at least there should be no special handling of that. Accessing cluster network A from cluster network B should be the same as accessing cluster network A from the outside.

Once we have both ingress and egress, we may be able to obsolete the custom solution on OVN-K introduced for HyperShift.

Who	What	Reference
DEV	Upstream roadmap issue	<link to GitHub Issue>
DEV	Upstream code and tests merged	<link to meaningful PR>
DEV	Upstream documentation merged	<link to meaningful PR>
DEV	gap doc updated	<name sheet and cell>
DEV	Upgrade consideration	<link to upgrade-related test or design doc>
DEV	CEE/PX summary presentation	label epic with cee-training and add a <link to your support-facing preso>
QE	Test plans in Polarion	<link or reference to Polarion>
QE	Automated tests merged	<link or reference to automated tests>
DOC	Downstream documentation merged	<link to meaningful PR>

depends on

SDN-4521 Ingress and egress for OVN Kubernetes secondary networks

RFE-4938 Support of egress and Service ingress for secondary OVN Kubernetes networks

is blocked by

CNV-24260 [TP] OVN Kubernetes multi-homing in CNV: IPAM

is depended on by

CNV-34629 Create secondary networks on AWS and ROSA (bare metal)

is related to

CNV-33753 OVN Kubernetes multi-homing in CNV: Egress