NO-JIRA: Branch Sync release-4.22 to release-4.21 [03-25-2026]#3087
NO-JIRA: Branch Sync release-4.22 to release-4.21 [03-25-2026]#3087openshift-pr-manager[bot] wants to merge 93 commits intorelease-4.21from
Conversation
Signed-off-by: Dan Winship <danwinship@redhat.com>
Ignore whitespace differences. Sort the output back into the "correct" order. Signed-off-by: Dan Winship <danwinship@redhat.com>
Replace the custom HTTP server in StartMetricsServer with MetricServer. Signed-off-by: Lei Huang <leih@nvidia.com>
A DPU firmware settings change can cause the same physical port to be re-enumerated under a different PCI address after a host reboot. Previously, Init() only handled missing device IDs (legacy annotations). Now it also detects when the annotated device ID is no longer present in the allocator and falls back to matching by PfId and FuncId. Signed-off-by: Yury Kulazhenkov <ykulazhenkov@nvidia.com>
Signed-off-by: Tim Rozet <trozet@nvidia.com>
Adds DPU blog
`kind setup` starts to fail with error: ``` ERROR: failed to load image: command "docker exec --privileged -i ovn-worker ctr --namespace=k8s.io images import --all-platforms --digests --snapshotter=overlayfs -" failed with error: exit status 1 Command Output: ctr: content digest sha256:9c04829e9...: not found ``` Related kind issue is kubernetes-sigs/kind#3795. This change uses the workaround mentioned in the kind issue. Signed-off-by: Lei Huang <leih@nvidia.com>
fix kind load docker-image content digest not found
Signed-off-by: fangyuchen86 <fangyuchen86@gmail.com>
Signed-off-by: Patryk Diak <pdiak@redhat.com>
The node gateway logic was not taking into account dynamic UDN. Therefore if a UDN was created with a service, but our node was not active, then at start up during syncServices we would fail due to GetActiveNetworkForNamespace failing. After 60 seconds of syncServices failling, it would lead to OVN-Kube node crashing. This commit introduces a common helper function to network manager api, ResolveActiveNetworkForNamespaceOnNode, which will allow legacy controllers that are not per-UDN or default controller to find the primary network serving a namespace for their node. The node/gateway is updated to use this function and during sync and allows us to ignore objects for which the network is not on our node with Dynamic UDN. Additionally it does not fail syncServices when a network is not found. During NAD controller start up, all networks will have been processed. If by the time gateway starts up and the network is missing, that means it is a new event which this node has never seen before. Therefore it is safe to skip it during syncServices and allow initial add handling to take care of it later. Signed-off-by: Tim Rozet <trozet@nvidia.com>
Network Policy add was not taking into account dynamic UDN. This was not a problem for the layer2/layer3 UDN controller side, because if the node was inactive, then the controllers wouldn't exist. However, it was a problem for the default network controller, because if the DNC could not get the active network, it would error and retry to add the KNP over and over again for other UDNs. This fixes it by checking the nad controller cache instead, which will always have the full info to determine if the KNP belongs to CDN. Furthermore, the delete KNP path was incorrect. It would try to get the active network which could be gone during deletion. This was unnecessary as the deleteNetworkPolicy code will check to see if it actually configured it in the first place, making it a noop to always call delete. Signed-off-by: Tim Rozet <trozet@nvidia.com>
Needed to be updated for the same reasons as network policy. Services controller is per UDN, and with an inactive node this is not a problem for UDN controllers as they will not exist. However, for DNC it would continue failing to get active network here. Use the nad controller cache and shortcut the checks for default network controller. Signed-off-by: Tim Rozet <trozet@nvidia.com>
Should always just return default network in that case. Signed-off-by: Tim Rozet <trozet@nvidia.com>
EF calls GetActiveNetworkForNamespace in an initialSync migration function. This function moves from cluster port group to namespace pgs. It is old and could be argued to just remove the code, but for now move to use nad controller cache. Also, do not cause OVNK to exit if we cannot get the network name, and just skip that entity. Signed-off-by: Tim Rozet <trozet@nvidia.com>
Egress IP controller runs as part of DNC, is event driven, and retries on failures. It is also not dynamic UDN aware. This commit aims to fix this by: - Change EgressIP to check with nad controller for network presence - If network is not processed/invalid skip retrying in egress IP controller - Register NAD Reconciler for Egress IP, so that when network becomes active Egress IP handles reconciliation. - If dynamic UDN is enabled, filter out EgressIP operations for inactive nodes. Overall this should be a quality of life improvement to EgressIP and reduce unnecessary reconcilation with UDN. Future steps will be to break Egress IP into its own level driven controller. Signed-off-by: Tim Rozet <trozet@nvidia.com>
Adds a test that creates a primary + secondary UDN, pod, egress IP, KNP, MNP objects in those UDNs. Then restarts every ovnkube-pod, and ensures it comes back up in ready state. This is useful in general to make sure we survive restarts correclty, but especially useful for Dynamic UDN where a network may not be active on a node and we want to ensure start up syncing is not failing because of that. Signed-off-by: Tim Rozet <trozet@nvidia.com>
When a pod is recreated with the same name, the egressIP cache could already
contain a “served” {EgressIP,Node} status and skip programming as a no-op.
Since statusMap keys do not include pod IP, LRP/NAT state could remain stale
and traffic would miss egressIP SNAT.
Fix by detecting pod IP drift from podAssignment.podIPs and forcing a
delete+add reprogram for already-applied statuses:
- compare cached pod IPs to current pod IPs
- queue existing statuses for reprogram on IP change
- delete old assignment state (without standby promotion) and re-add it
- then update cached pod IPs
Signed-off-by: Tim Rozet <trozet@nvidia.com>
EgressIP pod handling assumes pod networking setup has already populated logicalPortCache before egressIP reconciliation runs. That ordering holds within one controller queue, but breaks for primary UDNs where pod setup runs in UDN controllers while egressIP pod reconcile runs in the default controller. In that cross-controller race, egressIP reconcile can run first, fail to get pod IPs (stale/missing LSP), and wait for normal retry cadence even after UDN later updates port cache. Fix by wiring an immediate egressIP pod retry on logicalPortCache add: - add a base controller callback hook for logicalPortCache add events - invoke it from default/UDN pod logical port add paths - hook it for primary UDN controllers to enqueue no-backoff egressIP pod retry - centralize retry logic in eIPController.addEgressIPPodRetry() (including PodNeedsSNAT filtering) This preserves existing behavior while removing the UDN/DNC ordering race window for egressIP pod programming. Signed-off-by: Tim Rozet <trozet@nvidia.com>
Removes UnprocessedActiveNetwork Error, and moves to just using a single error, InvalidPrimaryNetworkError for everything. Modifies GetActiveNetworkForNamespace to return nil when there is no active network due to namespace being removed, or Dynamic UDN filtering. Callers can then rely on this function to determine whether or not a network is active versus the network should exist but doesn't (an error). Walked through all callers of GetActiveNetworkForNamespace and GetPrimaryNADForNamespace and tried to simplify number of calls and logic. Signed-off-by: Tim Rozet <trozet@nvidia.com>
- Removes a second call to GetActiveNetworkForNamespace during egress firewall add. We can just use the cache object that already exists. - Restructure the cache object to be a slice of subnets, rather than a string key. - Fix util function CopyIPNets, which was not doing a deep copy of the underlying IP/Mask slices. Signed-off-by: Tim Rozet <trozet@nvidia.com>
Code was modifying the annotations of the informer cache node object. If this was happening while another goroutine was reading the annotation map, it would trigger ovnkube to crash! Fixes: #5950 Signed-off-by: Tim Rozet <trozet@nvidia.com>
Signed-off-by: Tim Rozet <trozet@nvidia.com>
Gateway egress IP adds IPs to an annotation on the node. The code was assuming the informer object should have the latest data, then overwriting the IPs using that information. That isn't reliable as the informer could have stale data compared to recent kubeclient updates. This would trigger egress IP logic to corrupt the IPs in the node annotation, and cause further drift/corruption in subsequent updates. This fixes it by creating a local cache of IPs for the controller, and using that as the source of truth, initialized on start up from the node object. Then updates are driven by what is in the cache, versus what is in the informer. Also fixes places where tests should have been using Eventually. Signed-off-by: Tim Rozet <trozet@nvidia.com>
Signed-off-by: fangyuchen86 <fangyuchen86@gmail.com>
EgressIP: Fix crash from mutating node informer object
Fixes missing Dynamic UDN integration, Incorrect logic with GetActiveNetworkForNamespace, adds EgressIP NAD Reconciler
In Egress IP tracker when GetPrimaryNADForNamespace returns an InvalidPrimaryNetworkError we return nil during the sync, as we expect the NAD controller to deliver the event later when the NAD is processed. However, in this UT there is no full NAD controller and it relies on the lister. Therefore the UT may run before the informer cache is populated and never get notified from the "NAD Controller". To fix it, wait until the informer cache is populated and then simulate the NAD Controller behavior by Reconciling the NAD key. Fixes: #5953 Signed-off-by: Tim Rozet <trozet@nvidia.com>
Skip namespaces with deletionTimestamp set when selecting target namespaces, triggering NAD deletion for terminating namespaces. Signed-off-by: Patryk Diak <pdiak@redhat.com>
|
/test 4.21-upgrade-from-stable-4.20-e2e-aws-ovn-upgrade |
|
/payload-job periodic-ci-openshift-release-main-ci-4.21-upgrade-from-stable-4.20-e2e-azure-ovn-upgrade |
|
@jluhrsen: trigger 11 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/393b3f90-2f1c-11f1-93de-6ff832deab6b-0 |
|
/test 4.21-upgrade-from-stable-4.20-e2e-aws-ovn-upgrade |
|
/payload-job periodic-ci-openshift-release-main-ci-4.21-upgrade-from-stable-4.20-e2e-azure-ovn-upgrade |
|
@jluhrsen: trigger 11 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/16b99bb0-2fa8-11f1-829d-8e6dd6720ed2-0 |
|
/payload-job-with-prs periodic-ci-openshift-release-main-ci-4.21-e2e-aws-ovn openshift/origin#30977 |
|
@arkadeepsen: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/ca6b0310-3296-11f1-953a-3eec175873ae-0 |
|
/payload-job-with-prs periodic-ci-openshift-release-main-ci-4.21-e2e-aws-ovn openshift/origin#30977 |
|
@arkadeepsen: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/f0f99610-32ee-11f1-9ea2-b6c28c658aa1-0 |
|
/payload-job-with-prs periodic-ci-openshift-release-main-ci-4.21-e2e-aws-ovn openshift/origin#30977 openshift/multus-cni#284 |
|
@arkadeepsen: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/b24e2180-336e-11f1-8eef-893f056ce8e5-0 |
|
/payload-job-with-prs periodic-ci-openshift-release-main-ci-4.21-e2e-aws-ovn openshift/origin#30977 openshift/multus-cni#284 |
|
@arkadeepsen: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/1aba7c50-34ff-11f1-8881-f5621743b1c0-0 |
|
/payload-job-with-prs periodic-ci-openshift-release-main-ci-4.21-e2e-aws-ovn openshift/origin#30977 openshift/multus-cni#284 |
|
@arkadeepsen: it appears that you have attempted to use some version of the payload command, but your comment was incorrectly formatted and cannot be acted upon. See the docs for usage info. |
|
/payload-job-with-prs periodic-ci-openshift-release-main-ci-4.21-e2e-aws-ovn openshift/origin#30977 openshift/multus-cni#284 |
|
@arkadeepsen: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/c1cb8020-371b-11f1-8314-beaf8a27bf87-0 |
|
/retest-required |
|
/payload-job periodic-ci-openshift-release-main-ci-4.21-upgrade-from-stable-4.20-e2e-azure-ovn-upgrade |
|
@arkadeepsen: trigger 11 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/e72c26c0-37fd-11f1-9d53-82639997917e-0 |
|
/test e2e-aws-ovn-edge-zones |
|
/payload-job periodic-ci-openshift-hypershift-release-4.21-periodics-e2e-aws-ovn-conformance |
|
@arkadeepsen: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/0ebcfb40-3819-11f1-8e3f-e1e28df1fa3a-0 |
|
/test e2e-aws-ovn-edge-zones |
|
@openshift-pr-manager[bot]: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
16 participants
Automated branch sync: release-4.22 to release-4.21.