OCPBUGS-66428, CORENET-6055, OCPBUGS-66360, OCPBUGS-48710, OCPBUGS-66381: Branch Sync release-4.19 to release-4.18 [12-03-2025] #2895

jluhrsen · 2025-12-04T01:17:00Z

This is identical to the automated branch sync PR here, but two one line changes to fix the lint job. See that commit message for more details.

This PR is actually enabling linting so we never noticed the issue before. Although the issue was harmless no-op.

with this PR we are in sync with 4.19 like we want to be, with the exception of having to re-pin libreswan because of OCPBUGS-55453

OVN-Kubernetes is always lagging behind on the version of OVN it pins. This is causing a lot of trouble with keeping up with bug fixes and especially CVE fixes on older branches, resulting in scanners flagging this image with poor security grades and much longer time for bug fixes to be delivered to customers as the PR backporting process can take weeks or even months. Removing the pin, so every time the new build is released in FDP, it automatically gets into versions of OpneShift that use it. There is a pre-release testing process in place between FDP and OCP QE that ensures the required test coverage before the new build is released through FDP. Keeping OKD versions separate since sometimes new major versions are not released at the same time in FDP/RHEL and CentOS, so we may need them different at some point in time. Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

When multiple networks support was first added, all controllers that were added used the label "Secondary" to indicate they were not "Default". When UDN was added, it allowed "Secondary" networks to function as the primary network for a pod, creating terminology confusion. We now treat non-default networks all as "User-Defined Networks". This commit changes all naming to conform to the latter. The only places secondary is used now is for distinguishing whether or not a UDN is acting as a primary or secondary network for a pod (it's role). The only exception to this is udn-isolation. I did not touch this because it relies on dbIDs, which would impact functionality for upgrade. There is no functional change in this commit. Signed-off-by: Tim Rozet <trozet@nvidia.com> (cherry picked from commit bbca874)

The k8s e2e utility functions AddOrUpdateLabelOnNode/RemoveLabelOffNode don't work for labels without a value. The incorrect handling of these labels caused an incorrect sequence of nodes whem migrating different than what the tests intended to test. Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit 434b48f)

There's two circumstances when IPs were being released incorrectly: * when a live migratable pod completed with no migration ongoing it was not being released due to IsMigratedSourcePodStale outright assuming a completed pod was stale. * when a live migratable pod completed on a different node than the VM's original as part of a migration it was being released when it shouldn't, we were simply not checking if it was a migration. It also improves the tests to check for IP release. Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit 4c34982)

Don't attempt to release IPs that are not managed by the local zone which can happen with live migratable pods, otherwise we would get distracting error logs on release. Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit 7a155cc)

ConditionalIPRelease would always return false when checking IPs not tracked in the local zone so in that case we were not correctly checking for colliding pods. This was hidden by the fact that IsMigratedSourcePodStale was used just before instead of AllVMPodsAreCompleted until a very recent fix and that would always return false for a completed live migratable pod. Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit 0dc8f27)

Or completion of a failed target pod Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit c1b02b5)

As it is the most complex scenario and a superset of testing without it Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit ef92f78)

I accidentally removed the check in recent PR [1] which could have performance consequences as checking agains other pods has a cost. Reintroduce the check with a hopefully useful comment to prevent it form happening again. [1] ovn-kubernetes/ovn-kubernetes#5626 Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit 76f6439)

When processing pods during an EgressIP status update, the controller used to stop iterating as soon as it encountered a pod in Pending state (in my case, pod IPs are not found when pod is in pending state with container creating status). This caused any subsequent Running pods to be skipped, leaving their SNAT entries unprogrammed on the egress node. With this change, only Pending pods are skipped, while iteration continues for the rest. This ensures that Running pods are properly processed and their SNAT entries are programmed. This change also skips pods that are unscheduled or use host networking. Signed-off-by: Periyasamy Palanisamy <pepalani@redhat.com> (cherry picked from commit 2afbaf6)

…d_4.20 [release-4.20] OCPBUGS-63631: Skip Pending pods in EgressIP status updates

When processing pods during an EgressIP status update, the controller used to stop iterating as soon as it encountered a pod in Pending state (in my case, pod IPs are not found when pod is in pending state with container creating status). This caused any subsequent Running pods to be skipped, leaving their SNAT entries unprogrammed on the egress node. With this change, only Pending pods are skipped, while iteration continues for the rest. This ensures that Running pods are properly processed and their SNAT entries are programmed. This change also skips pods that are unscheduled or use host networking. Signed-off-by: Periyasamy Palanisamy <pepalani@redhat.com> (cherry picked from commit 2afbaf6)

…rry-pick-2721-to-release-4.20 OCPBUGS-63577: [release-4.20] CORENET-6055: Dockerfile: Unpin OVN and consume the latest from FDP.

…rry-pick-2831-to-release-4.19 [release-4.19] OCPBUGS-63660: Skip Pending pods in EgressIP status updates

configure IP/VRF rules only on full/dpu-host mode, and confiugre openflow rules only on full/dpu mode. Signed-off-by: Yun Zhou <yunz@nvidia.com> (cherry picked from commit a996442)

Signed-off-by: Yun Zhou <yunz@nvidia.com> (cherry picked from commit 60404e5)

OCPBUGS-63007: kubevirt: fix bad release of IPs of live migratable pods